AFHRL-TR-6843 


DEVELOPMENT  AND  APPLICATION  OF  COMPUTER 
SOFTWARE  TECHNIQUES  TO  HUMAN  FACTORS 
TASK  DATA  HANDLING  PROBLEMS 


A.  T  TI  LLEY 
C  R.  MEYER 
ft.  G.  OLLEti 
P,  J  MITCHELL 
S.  E  REARDON 

System  Deielojmieni  Corporation 
and 

L.  E.  REED 

Air  Force  Human  Resources  Laboratory 


TECHNICAL  REPORT  AFHRL  TR-68  13 


NOVEMBER  1968 


This  doc  ument  has  been  approved  tor  public 
release  and  sale,  its  distribution  is  unlimited. 


AIR  FORCE  HUMAN  RESOURCES  LABORATORY 
AIR  FORCE  SYSTEMS  COMMAND 
WRIGHT-PATTERSON  AIR  FORCE  BASE,  OHIO 


NOTICE 


When  Government  drawings,  specifications,  or  other  data  are  used  for  any  purpose 
other  than  in  connection  with  a  definitely  related  Government  procurement  operation, 
the  United  States  Government  thereby  incurs  no  responsibility  nor  any  obligation 
whatsoever;  and  the  fact  that  the  Government  may  have  formulated,  furnished,  or  in 
any  way  supplied  the  said  drawings,  specifications,  or  other  data,  is  not  to  be  regarded 
by  implication  or  otherwise  as  in  any  manner  licensing  the  holder  or  any  other  person 
or  corporation,  or  conveying  any  rights  or  permission  to  manufacture,  use,  or  sell  any 
patented  invention  that  may  in  any  way  be  related  thereto. 

This  document  has  been  approved  for  public  release  and  “"le;  its  distribution  is 
unlimited. 


\ 

] 


Copies  of  this  report  should  not  be  returned  unless  return  is  required  by  security 
considerations,  contractual  obligations,  or  notice  on  a  specific  document. 


900  -  J*.:uary  1969  -  C.045S  -  63 -14  IS 


AFHRL-TR-6f  3 


i 


DEVELOPMENT  AND  APPLICATION  OF  COMPUTER 
SOFTWARE  TECHNIQUES  TO  HUMAN  FACTORS 
TASK  DATA  HANDLING  PROBLEMS 


A.  T.  TULLEY 
G  R.  MEYER 
R.  G  OILER 
P.  J  MITCHELi 
S.  E.  REARDON 

System  Development  Corporation 
and 

L  E  REED 

Air  Force  Human  Resourc  es  Laboratory 


This  document  has  been  approved  for  public 
release  and  sale,  its  distribution  is  unlimited 


FOREWORD 


This  report  was  prepared  by  the  Technical  Information  Systems  Department  of 
System  Development  Corporation  for  the  Training  Research  Division  of  the  Air 
Force  Human  Resources  Laboratory,  Wright-Patterson  Air  Force  Base,  Ohio. 

Mr.  A.  T.  Tulley  of  the  System  Development  Corporation  was  the  principal 
investigator.  The  research  *vas  conducted  under  Contract  F3361 5-67-C- 1036 
during  the  period  1  July  1 967  through  27  September  1968.  Prior  to  the 
establishment  of  the  Air  Force  Human  Resources  Laboratory  on  1  July  1968, 
the  Training  Research  Division  was  an  element  of  the  Aerospace  Medical  Research 
Laboratories . 

The  ^search  was  conducted  'in  support  of  Project  1710,  "Human  Factors  in  the 
Design  of  Training  Systems,"  and  Task  171006,  "Personnel,  Training  and  Manning 
Factors  in  the  Conception  and  Design  of  Aerospace  Systems."  \  Gordon 
Ecks  and  (HRT)  was  the  Project  Scientist  and  Mr.  Melvin  T.  Snyder  (HRTR) 
was  the  Task  Scientist.  Mr.  Lawrence  E.  Reed  (HRTR)  served  as  the  contract 
technical  monitor. 

This  report,  a  companion  to  AMRL-TR-66-20U,  "Development  and  Application  of 
Computer  Software  Techniques  to  Human  Factors  Task  Data  Handling  Problems," 
represent'  a  part  of  a  total  effort  directed  to  the  development  of  techniques 
for  handling  human  factors  task  data.  Other  reports  in  the  series  are  cited  in 
Section  I  of  this  report. 

The  authors  wish  to  thank  the  many  government  and  contractor  personnel  who 
contributed  valuable  suggestions  throughout  the  course  of  this  research. 

Special  thanks  are  due  Mr.  Melvin  T.  Snyder,  who  assisted  in  the  review  of 
the  manuscript  and  Mrs.  Joan  C.  Robinette  for  her  editorial  assistance. 
Acknowledgement  is  also  made  to  other  System  Development  Corporation  personnel : 
Messrs.  A.  S.  Cooperband,  R.  Oanchick,  S.  Fisher,  Theodore  Hamlet,  H.  Manelo- 
witz,  H,  Sapan  and  J.  E.  Wimberley  who  served  as  advisors  and  technical 
consultants  during  the  period  covered  and  Mr.  Donald  E.  Blair  who  edited  this 
report . 

This  technical  repor'  has  been  reviewed  and  is  approved. 


GORDON  A.  ECKSTRAND,  PhD. 

Chief,  Training  Research  Division 
Air  Force  Human  Resources  Laboratory 


1 1 


ABSTRACT 


Research  leading  to  the  application  and  implementation  of  techniques  for 
computer  handling  of  hunan  factors  task  data  generated  in  support  of  'ro- 
space  system  development  programs  is  discussed.  The  technique  development 
is  based  on  the  assumption  that  a  user-oriented  computerized  data  handling 
system  will  help  draw  human  factors  specialists  closer  to  needed  data.  The 
application  of  these  techniques  should  reduce  the  problem  of  data  accessi¬ 
bility  and  allow  more  effective  use  of  data  in  the  system  design  and  devel¬ 
opment  process.  A  computerized  data  handling  system  to  store,  selectively 
retrieve,  and  process  human  factors  data  in  a  user-oriented  environment 
was  iHiplemeiited  through  a  :  i!ct  study  Exper imciiLal  ryct"»»  (PSES). 
experimental  system  provided  the  primary  means  for  evaluating  the  research 
results.  This  report  discusses  the  development  process  of  the  PSES,  the 
computer  software  used  by  the  PSES,  data  classification  techniques,  and 
vocabulary  controls.  Consideration  is  also  given  to  the  feasibility  of 
providing  (1)  analytic  and  simulation  tools  in  a  user-oriented  environment, 
(2)  current  awareness  notification  of  data  entries,  and  (3)  an  advanced 
and  sophisticated  classification  scheme  for  identifying  functional  rela¬ 
tionships. 
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SECTION  I 


DEVELOPMENT  AND  APPLICATION  OF  TASK  DATA  HANDLING  TECHNIQUES 


OVERVIEW  OF  THE  PROBLEM 

The  importance  of  ensuring  early  human  factors  considerations  in  the  design 
of  aerospace  systems  has  long  been  recognized  by  both  government  and  indus¬ 
trial  specialists.  The  ever  increasing  complexity  cf  today's  advanced  sys¬ 
tems  demands  that  human  performance  considerations  be  an  integral  part  of  the 
overall  system  performance.  While  government  agencies  have  instituted  vari¬ 
ous  programs  to  ensure  proper  consideration  of  the  human  element,  e.g.,  the 
Personnel  Subsystem  program  in  the  Air  Force,  the  sheer  speed  of  system  de¬ 
velopment  has  placed  3n  almost  impossible  burden  on  human  factors  specialists. 
Both  the  amounts  of  information  generated  and  the  compressed  system  develop¬ 
ment  schedules  have  led  the  specialist  to  rely  heavily  on  his  own  expertise 
when  data  are  not  known  to  exist  or  are  inaccessible.  As  a  result,  the  in¬ 
put  to  early  identification  of  human  factors  requirements  and  the  integration 
of  these  req  irements  into  system  design  have  not  been  satisfactory. 

The  research  reported  here  was  designed  to  study  ways  to  alleviate  some  of 
these  problems  through  the  application  of  computer  technology.  The  tech¬ 
niques  exploded  in  this  researcn  program  are  based  on  the  assumption  that  a 
user-oriented,  computer  based,  data  nandling  v.stem  will  help  draw  human  fac¬ 
tors  specialists  closer  to  r\  led  data  and  that  the  application  of  such  a 
system  will  help  rcouce  the  problem  of  data  accessibi 1 i ty  and  allow  more  ef¬ 
fective  use  of  data  in  the  system  design  and  development  process. 


RESEARC:-  GDAiF 

The  research  goals  are  directed  toward  the  develop  ment  of  techniques  that 
will  aid  the  human  factors  specialist,  both  in  government  and  industry,  to 
improve  the  effectiveness  of  data  in  the  development  process  of  systems. 

These  goals  are: 

*  prqvjde  a  means  by_  which  data  car  be  accessed  when  and  where  they  are 
needed 

The  data  system  must  provide  rapid  access  to  information  on  personnel  and 
training  requirements ,  facilities,  equipment,  and  other  task  related  Infor¬ 
mation  generated  at  any  point  in  the  development  cycle  o(  systems . 

*  Provide  data  for  any  p.._ct  of  a  system  duplicated  in  past  systems  or 
cur  rent  sy r  terns 

TTiTs  goat  is  directed  to  alleviating  th*>  problem  of  duplicate  generation 
of  data.  Information  generated  in  support  of  one  system  should  be  avail¬ 
able  for  maxing  decisions  on  new  systems . 

*  Fro, >de  a  store  rf  data  from  which  the  user  -av  retrieve  selectively 
This  qcal  is  >ean?  to  alleviate  the  problem  of* accessing  the  Increasing 
volume  of  data  generated  if  support  c.f  systems.  At  ary  point  in  time,  the 
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specialist  is  usually  interested  ip  obtaining  particular  data  cr  combina¬ 
tions  of  data  and  nothing  else. 

*  Provide  data  that  are  current  and  frequently  updated 

T7_r!ifi  time  required  to~avaiT"the  user  of  needed  information  is  greater 
than  the  time  it  takes  for  information  to  change,  then  the  information  in 
the  data  system,  though  important  to  applications  or  other  systems,  may  be 
inadequate  for  immediate  use.  Since  the  data  generated  in  support  of 
systems  have  a  raoid  decay  rate,  the  data  user  must  be  provided  with  the 
latest  information  as  Quickly  as  possible. 

*  Provide  basic  analytic  focls 

Gainer- 'than  force  the  user  to  apply  specific  analytic  techniques  to  his 
data,  the  data  sytsem  should  allow  the  user  to  select  from  a  pnol  of  exist¬ 
ing  analytic  routines,  O;  simultaneously  write  and  operate  new  analytic 
routines  that  meet  his  need. 

*  Provide  a  standard  language  without  "due  constraint,  on  the  user 
Technical  "Perms  describing  human  behavior  are  usually  ambi guous- and  redun¬ 
dant.  Some  means  of  vocabulary  control  must  be  provided  sc  that  data  may 
be  retrieved  consistently  by  different  users. 


RESEARCH  APPROACH 

Figure  1  illustrates  the  research  activities  leading  to  the  application  and 
implementation  of  computer  techniques  for  handling  human  factors  task  data 
generated  in  support  of  aerospace  system  development  programs.  The  activi¬ 
ties  are  grouped  into  three  areas  of  study,  v ’ z . ,  Preliminary  Research, 

Pilot  Study,  and  Pilot  Study  Experimental  System  (PSES). 

Preliminary  Research 

The  objective  of  the  preliminary  research  was  to  identify  problem  areas  and 
to  determine  the  feasibility  of  developing  improved  methods  for  handling 
human  factors  task  data.  It  was  recognized  early  in  the  research  program  that 
technic  'es  for  data  handling  must  be  developed  in  context  with  the  total  en¬ 
vironment  in  which  they  are  to  operate.  Knowledge  about  the  types  of  data  to 
be  handled,  the  neeos  of  generators  and  users  of  data,  and  the  needs  for  data 
handling  is  a  prerequisite  to  the  design  of  such  a  system.  Thus,  before  re¬ 
commendations  for  developing  specific  techniques  could  be  made,  the  research 
was  directed  ,u  the  fulfillment  of  the  following  objectives: 

•  identify  the  representati ve  groups  of  technical  and  proiessional  special¬ 
ists  involved  in  the  generation  and  use  of  human  factors  task  information 

•  Identify  the  types  and  classes  of  d.  fa  generated,  used,  aid  required  by  the 
government  and  its  contractors  in  system  design,  development,  and  operation 


Identify  the  relationships  between  data  categories,  the  input/outpui  char¬ 
acteristics  of  the  data,  and  the  various  phases  in  system  devel*  ,  lent  under 
which  the  data  ur„  generated  and  used 


•  Describe  the  uses  of  the  data  in  making  system  design,  development,  oper¬ 
ation  ano  related  management  decisions 

•  Assess  the  types  of  current  and  potential  uses  of  computers  for  handling 
system  data 

•  Assess  the  current  and  desired  data  retrieval  times 

•  Recommend  the  desired  characteristics  for  a  technical  data  handling  system 
to  operate  in  a  government/contractor  environment 

In  response  to  the  preceding  objectives,  information  was  gathered  through  an 
extensive  review  of  the  literature,  interviews  with  pertinent  government  and 
Industry  personnel,  and  from  responses  to  questionnaires. 

The  results  of  the  preliminary  research  are  reported  in: 

Hannah,  L.  D,;  Boldovici,  J.  A.;  Altman,  J.  W.;  and  Manion,  R.  C.  The  Role 
of  Human  Fact.rs  Task  Data  in  Aerospace  System  Desiqn  and  Development. 

mu^^rrrjm  Srw. - — - — - 

Hannah,  L.  D.  and  Reed,  L.  E.  Basic  Human  Factors  Task  Data  Relationships 
in  Aerospace  Systems  Design  an'cf'De'veTopmeiit,  AHkL-Tk-65-231  (AD  63c  '63517 

Whiteman,  I.  R.  The  Role  of  Computers  in  Handling  Aerospace  Systems  Human 
Factors  Task  DataTlMRL-tR-65-206 (AD  WT3~2T 

Pilot  Study 

The  objectives  of  the  initial  study  effort  beyond  the  preliminary  research  was 
to  define  requirements  and  develop  techniques  for  the  computerized  handling  of 
human  factors  task  data.  Research  was  divided  into  six  distinct  efforts  (see 
figure  1):  (1)  Derive  Operational  System  Requirements;  (2)  Derive  Operational 

System  Concept;  (3)  Define  Pilot  Study  Requirements ;  (4)  Select  Research  Areas; 
(5)  Conduct  Research,  and,  (6)  Develop  Pilot  Study  Design  Specifications. 

The  results  of  the  initial  research  are  reported  in: 

Potter,  K.  W.;  Tulley,  A  T,;  and  Reed,  L.  E.  Development  and  Application 
of  Computer  Software  Techniques  to  Human  Factors  Task  Data  HdlidTi ng  "ProFTems , 

(ad  64>  mr. 

Derive  Operational  System  Requirements 

An  extensive  review  of  the  recommendations,  information,  and  experience  re¬ 
sulting  from  the  preliminary  research  led  to  the  determination  of  14  re¬ 
quirements  for  the  development  of  an  operational  data  handling  system.  These 
•'equirements  provided  the  guidelines  for  the  pilot  study  research  and  for 
the  development  of  an  experimental  system.  The  requirements  are: 

(1)  The  system  must  be  oriented  to  user  requi rements .  It  must  satisy  tne 

of  aerospace  scientists  and  engineers  arid  must  fulfill  management 
needs  for  data. 
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(2)  The  system  must  provide  Tor  the  storage,  updating,  end  retrieval  of  Hu¬ 
man  factors  task  data.  The  data  should  be  indexed  to  permit  retrieval 
based  on  several  reference  points. 

(3)  The  data  system  must  be  responsive  to  current  Air  Force  and  National 
Aeronautics  and  Space  Administration  (NASA)  system  and  data  management 
concepts.  Compatibility,  rather  than  dependability,  with  the  system 
engineering  process  is  recommended . 

(4)  The  system  must  provide  simplicity  of  use  by  accepting  and  outputting 
data  in  a  form  approaching  user  terminology.  All  inputs  and  outputs 
must  be  immediately  interpretable  by  the  user.  This  includes  all  data, 
whether  they  are  qualitative  or  quantitative  in  nature. 

(5)  The  user  of  the  data  system  must  have  easy  access  to  the  stored  data 
through  the  use  of  a  user-oriented  query  language.  The  terminology 
interpreted  by  the  system  must  be  compatible  with  the  language  employed 
by  the  user  in  his  system-specific  activity. 

(6)  Provisions  must  be  made  for  external  storage  of  data  that  cannot  be 
coded  economically  for  computer  storage.  Where  applicable,  cross-in¬ 
dexed  data  should  be  stored  in  the  computer  for  referencing  information 
filed  externally,  e.g.,  documents,  pictures  and  graphs. 

(7)  The  data  bank  structure  must  be  flexible  enough  to  allow  for  future 
expansion  and  inclusion  of  additional  elements--c.at.egories  of  in¬ 
formation.  This  flexibility  will  allow  for  changes  in  data  concepts 
and  new  system  requirements  and  avoid  major  changes  in  the  structure  of 
the  data  base. 

(8)  The  data  bank  must  be  capable  of  frequent  updating  while  retaining 
selected  data  for  such  uses  as  design  trend  analysis.  The  system  must 
be  capable  of  purging  unwanted  historical  information.  The  updating 
capability  of  the  system  should  a^ow  for  the  storage  of  information 
generated  in  support  of  on-going  phases  of  an  aerospace  system  life 
cycle. 

(9)  The  data  system  must  be  Capable  of  retrieving  similar  information  gen¬ 
erated  in  support  of  different  aerospace  systems.  This  capability  will 
allow  maximum  use  of  data  in  making  design  decisions  for  new  systems. 

(10)  The  data  sysf>'„  must  be  capable  of  selectively  retrieving  data  elements 
by  qualifying  them  with  other  data  elements,  With  this  capability,  the 
user  receives  only  the  data  he  needs  and  nothing  else. 

(11)  The  data  system  must  have  the  capability  of  orotecting  data  naving 
security  classification  and/or  proprietary  status. 

(12)  The  data  system  must  provide  the  capability  of  processing  retrieved 
data  through  the  use  of  analytic  programs  and  simulation  models  with 
a  minimum  of  human  intervention. 


(13)  The  system  must  provide  the  user  freedom  ir,  specifying  the  format  of 
outputs. 

(14)  The  system  must  provide  for  current  awareness  notifications  to  quali¬ 
fied  users.  In  response  to  interest  profiles.  A  notification  is  de¬ 
fined  as  a  statement  (via  teletype)  that  data  meeting  the  requirements 
of  a  qualified  user  have  been  added  to  the  information  store. 

Derive  Operational  System  Concept 

A  concept  of  an  operational  system  for  handling  and  processing  aerospace  sys¬ 
tem  hunan  factors  data  in  a  government/ industry  environment  was  developed  to 
lend  a  realistic  context  to  the  research  (Reed  and  Wise,  1965).  The  concept 
was  derived  from  the  preceding  operational  system  requirements  and  was  used 
to  assist  In  identifying  problems  for  research. 

A  brief  description  of  this  concept  is  presented  next. 

Figure  2  illustrates  the  conceptualized  operating  system  in  an  Air  Force  en¬ 
vironment.  The  Data  Exchange  Center  is  the  heart  of  the  system  which  con¬ 
sists  of  computer  hardware,  computer  programs,  data  storage,  and  a  data  con¬ 
trol  group. 


Figure  2.  Conceptualized  Operating  System 


-6- 


For  purposes  of  dii  jssion.  It  will  be  assumed  that,  a  data  exchange  center 
is  located  at  an  Air  Force  Systems  Conmand  (AFSC)  Division.  Subcontrac¬ 
tors  provide  prime  contractors  with  data.  The  prime  contractor  integrates 
these  data  with  his  own  and  rends  them  to  the  data  exchange  center  in  a  for¬ 
mat  ready  for  input  to  the  computer.  New  da+a  and  updates  will  be  entered 
in  the  data  bank  on  a  continuous  basis— not  just  at  design  milestones.  The 
data  bank  contains  human  factors  data  from  several  aerospace  systems.  This 
makes  it  possible  for  a  System  Program  Office  (SPO),  or  $PO-designated  users, 
to  compare  data  longitudinally  within  a  system  and  across  systems. 

All  of  the  techniques  and  programs  available  at  the  data  exchange  center  are 
available  to  contractors  for  use  on  their  own  computer  equipment.  If  certain 
special  techniques  such  as  large-scale  simulation  cannot  be  conducted  at  the 
local  center,  the  services  of  th&  data  exchange  center  may  be  requested 
through  the  appropriate  SPO. 

Two  modes  of  communication  with  ^he  data  exchange  renter  are  used.  SP0‘s  and 
user  commands  have  direct  communication  with  the  data  bank  by  means  cf  tele¬ 
types  operating  in  a  time-shared  mode.  Requests,  short  responses  to  requests, 
and  current  awareness  notifications  can  be  sent  economically  over  teletype 
line^.  Postal  services  are  used  to  deliver  large  volume  printouts.  Otner 
users  will  use  postal  services  or  teletype  to  the  SPO  control  group  for  all 
input  and  output  communications. 

Tne  central  processing  unit  f  see  figure  3)  must  be  a  medium  to  large  computer 
with  features  adaptable  to  time-shared  multiprocessing  and  multiprogramming 
operations.  It  must  have  an  extremely  flexible  growth  potential  for  in¬ 
creased  processing  power  ad  storage  capability. 

The  input/output  (I/O)  processor,  shown  separately,  controls  all  data  trans¬ 
fers.  It  allows  the  central  processor  to  be  free  to  continue  basic  process¬ 
ing  while  various  priorities  of  data  transfers  are  handled  separately.  Among 
these  priorities  are  teleprocessing  traffic,  memory  transfers,  and  peripheral 
buffering. 

The  data  bank  memory  consists  of  a  variety  of  storage  capabilities,  ranqinq 
from  direct  ra-  lorn-access  to  off-line  cards  and  tapes.  Because  of  the  vol¬ 
ume  and  growth  rate  cr  the  data  bank,  additions  to  storage  are  required  from 
time  to  time.  Microfilm  storage  supplements  the  data  bank.  An  index  to  the 
microfilm  is  maintained  in  the  data  bank.  Thus,  as  data  are  retrieved  from 
the  computer  storage,  references  are  listed  for  supplemental  retrieval  from 
mi c  rof i 1 m. 


Teleprocessing  capability  is  described  here  as  a  direct  hookup  of  remote  and 
on-line  teletype  stations  with  the  I/O  central  processor.  These  stations  may 
be  in  the  computer  room,  SPO's  in  the  same  building,  or  across  the  country. 

A  combination  of  hardware  and  software  safeguards  protects  proprietary  and 
classified  information. 


The  ST  j  control 
facility.  This 
The  group  would 


group  assists  and  monitors  the  data  cvcle  within 
group  would  be  an  extension  of  pach  of  the  S PC  s 
hopefully  stimulate  cross-talk  between  *he  SPO's 


the  exchange 
i nvol ved . 
and  provide 


Figure  3.  Ooeraticn  of  Data  Exchange  Center 


an  added  measure  of  control  on  proprietary  information.  They  a  re  responsible 
for  the  collection,  review,  and  verification  of  incoming  data.  Thev  also 
maintain  the  software;  handle  the  reproduction  of  materials  including  data 
lists,  charts,  and  reports;  and  monitor  the  reloa^ability  of  all  outputs. 

Define  Pilot  Study  Requirements 

Pilot  study  requirements  were  developed  to  focus  more  clearly  on  the  opera¬ 
tional  aspects  of  computer  software  functions.  A  concept  of  the  comnuter 
software  functions  was  developed  to  exemplify  the  inner  working  of  an  opera¬ 
tional  system  and  to  narrow  '■‘own  the  identification  of  research  areas  dis¬ 
cussed  next. 

Select  Research  Areas 

Five  areas,  considered  fundamental  from  the  standpoint  of  studying  the  pro¬ 
blem  and  proposing  solutions,  were  identified.  These  five  areas  are  pre¬ 
sented  and  discussed  below: 

•  Analysis  of  Human  Factors  Task  Data,  Data  Relation<nips ,  and  Classifi¬ 
cation  Schemes 
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One  of  the  most  important  considerations  in  applying  information  system 
techniques  to  data  handling  problem.,  is  the  determination  of  t,!e  charac¬ 
teristics  of  the  data  to  be  handled  by  the  system.  The  factor?  involved 
in  gaining  a  complete  understanding  of  the  data  include  their  diversity, 
application,  environment,  content,  life  cycle,  and  significant  phases  in 
their  generation  and  use.  The  personnel  involved  in  data  handling  are 
also  important  factors--their  problems,  response  times,  tools,  scheduling 
and  products.  Therefore,  an  analysis  of  the  data  and  of  the  people  direct 
ly  concerned  with  the  data  is  needed. 

*  Vocabulary  and  Thesaurus  Techniques  Applied  to  Human  Factors  Task  Data 

A  capability  that  increases  the  effectiveness  of  communication  among 
man/machine/software  functions  is  highly  desirable  in  computer  systems. 
Vocabularies  in  today's  systems  cannot  be  used  as  off-the-shelf  components 
they  must  be  tailored  to  the  environment  of  the  system.  In  this  research 
program,  a  special  consideration--standardization--is  apparent  in  study¬ 
ing  task  data  terminology.  Not  only  is  the  problem  apparent  for  treating 
multisystem  data,  but  also  in  providing  fen  mui +uis°nc  a  d*+a  vocabulary 
is  essential  to  this  information  system  and  requires  careful  study  in  its 
appl i cation. 

•  Computer  Storing  and  Retrieval  uf  Human  Factors  Task  Data 

Particular  problems,  identified  in  the  preliminary  research  program 
(Hannah  et  al . ,  1965),  that  directly  concern  users  of  task  data  are  the 
hand  1 1 rig  of  large  amounts  of  data,  dealing  with  scattered  sources,  and 
drawing  from  previous  and  current  experience  with  systems.  The  recommen¬ 
dations  resulting  from  the  preliminary  "esearch  call  for  a  store  of  infor¬ 
mation,  mutually  available  to  those  who  require  such  information,  in  a 
form  that  expedites  the  use  of  that  information.  The  recommendations  led 
to  the  conclusion  that  a  factual  storage  and  retrieval  capability  i< 
needed  which  always  keens  data  up-to-date. 

*  Analytical  and  Simulation  Mi  'g 1 i ng  Techniques  Applied  to  Human  Factors 
Task  Da_ta 

Techniques  employed  by  analysts  in  refining  task  data  into  useful  products 
are  oi  ten  the  result  of  scientific  analysis  and  modeling  procedures.  Such 
procedures  are  highly  amenable  to  computer  applications.  If  raw  quanti¬ 
tative  data  are  easily  accessible  it  a  computer  store,  various  processing 
techniques  car,  he  irinedi ately  and  directly  applied  to  retine  the  data  into 
the  required  products. 

•  Current  Awareness  Techniques  Applied  to  Human  factors  Task  Data 

A  special  problem  pointed  out  by  Hannah  et  al.tl965)  concerns  the  ina¬ 
bility  jf  analysts  to  keep  up  with  the  fast  pace  or  data  generation.  This 
is  particularly  true  when  the  data  are  scattered,  or  f  channels  providing 
awareness  are  inefficient.  Inefficiency  is  almost  always  present  when 
several  separate  orqani za t i ens  are  involved.  The  requirement  that  spe¬ 
cialists  be  immediately  aware  of  the  generation  of  data,  when  they  are  per 
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tlnent  to  their  interests , can  be  facilitated  by  the  functioning  of  a  com¬ 
mon  data  store.  The  problem  of  assuring  awareness  can  be  lessened  by  set¬ 
ting  up  a  major  automated  control  point  th»t  acts  as  a  disseminator  and 
provide,*  notification  of  pertinent  data  to  inteies  ted  pc  cple.  The  opera¬ 
tional  system  can  act  as  the  control  point. 

Conduct  Research 


The  activity  during  this  stage  led  to  the  formulation  of  an  initial,  y^t 
detailed,  design  This  activity  included  describing  particular  problems  and 
objectives  for  each  research  area,  as  well  as  planning  and  carrying  on*  ^ne 
research.  Figure  4  shows  the  interface  relationships  of  the  five  research 
areas.  The  results  provided  the  basis  for  the  development  of  the  pilot  study 
design  specifications.  The  nature  of  the  operational  system  concept  and  its 
man/machine  functions  became  clearer  as  problems  were  explored.  Modifications 
to  the  concept  were  made  during  the  course  of  the  study,  as  shown  fy  the  feed¬ 
back  loops  in  figure  1.  The  results  of  the  research  in  each  of  the  five  areas 
are  reported  in  Potter  et  al.  (1966)  and  -n  Sections  III  through  VII  of  this 
report. 

Develop  Pilo t  Study  Design  Specifications 

The  pilot  study  design  specifications  were  generated  in  response  to  the  re¬ 
search  results  drawn  from  the  five  research  areas  discussed  previously.  The 
specifications  describe  and  identify  the  requirements,  techniques,  functional 
interface,  and  approach  necessary  for  the  development  of  a  data  handling  sys¬ 
tem.  Since  the  objective  of  the  research  was  not  to  develop  a  full  operating 
system,  but  rather  to  explore  techniques  necessary  for  such  a  system,  the 
specifications  also  identify  those  areas  which  are  carried  into  computer  soft¬ 
ware  and  those  which  w*ll  be  tested  manually  or  given  narrative  treatment. 
These  specifications  included  such  topics  as:  detaile  characteristics  of 
the  data  used  as  inputs,  necessary  software  required  for  input,  retrieval, 
update  and  output,  thesaurus,  analysis  and  simulation,  user's  and  controller’s 
guides,  and  the  environment  necessary  to  support  the  development  of  the  data 
system.  The  design  specifications  provided  both  a  direction  for  research  and 
an  approach  to  be  usea  in  the  development  of  an  experimental  data  system. 

The  specifications  are  reported  in: 


Tulley,  A.  T.  and  Meyer,  G.  R.  Implementation  of  Computer  Software  rocn - 
niques  to  Human  Factors  Task  Data  Handling^  obie">s .  ^Mfti-T9-67-l?7  663 

D i 1 g t  Study  Experimental  System 

The  Pilot  Study  Experimental  System  ( P S E S )  encompasses  all  research  areas  tha* 


are  carried  to  test  and  evaluation  and  will  ultimately  resu 
tions  for  the  development  of  an  operational  data  handling  s 
development  was  divided  into  four  distinct  efforts:  ,1'  ! 
Study  Experimental  5ys tem  Design,  (  >)  Develop  Pile*  Study 
tern,  (3)  Conduct  Tests,  and  (4)  Evaluate  Test  Results  and 


It  in  recomre»da- 
vste"\  The  PSES 
dent  i  fv  "il.it 
F xperirenta!  Sys- 
p rep a  re  Per  onmen  - 


dations . 


ANALYSIS  OF  TASK  DATA,  RELATIONSHIPS,  AND  CLASSIFICATION 


INPUT/OUTPUT 

REQUIREMENTS 


Figure  4,  Interface  of  Research  Areas 
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Identify  Pilot  Study  Experimental  System  Design 


The  design  specifications  of  an  experimental  system  satisfy  those  areas  of 
the  pilot  study  that  are  carried  into  the  development  of  a  computerized  eval¬ 
uative  system  for  handling  human  factors  task  data.  The  specifications,  re¬ 
ported  in  Tulley  and  Meyer  (1967),  resulted  in  the  development  of  the  PSES. 
The  PSES  provided  the  means  by  which  data  handling  techniques  were  tested  and 
evaluated. 


Develop  Pilot  Study  Experiment al  System 

The  PSES  was  developed  to  focus  more  clearly  on  all  aspects--hardware,  soft¬ 
ware  personnel,  environment,  etc. --of  a  total  operating  data  system.  While 
the  PSES  was  not  regarded  as  an  operational  system  for  field  use,  it  did  pro¬ 
vide  a  means  for  determining  the  feasibility  cf  such  a  system.  The  processes 
and  steps  that  led  to  the  development  of  the  PSES  are  discussed  in  Sections 
II  and  III  of  this  report.  The  development  procedures  included:  (1)  the 
generation  of  an  experimental  data  pool,  (2'  the  application  of  computer 
techniques,  (3)  interim  development  tests,  and  (4)  implementation  of  modifi¬ 
cations  to  the  PSES  in  accorda  ce  with  test  results. 


The  design  of  any  information  system  is  based  upon  its  functions,  that  is, 
what  it  is  intended  to  do.  The  system  requirements  (see  page  4  1  specify  the 
conditions  for  handling  task  data  in  a  computerized  system.  ;  eluded  in  the 
requirements  are  stipulations  that  affect  the  manner  in  which  the  conditions 
are  met,  such  as  user  orientation,  selectivity  ir  retrieval,  vocabulary  stand¬ 
ardization.  To  the  extent  possible,  these  conditions  were  applied  to  the 
development  of  the  PSES.  Staie-of-the-art  considerations  were  determining 
factors  with  regard  to  the  application  of  computer  hardware  and  software  to 
the  PSES  functions.  Manual  operations  were  applied  where  automation  was  im¬ 
possible  or  impractical.  For  example,  vocabulary  control  was  achieved  bv 
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Conduct  Tests 


When  3  relatively  f-  concept  of  the  svste-  "ad  beer  achieve-.:  ard  a  set  o' 
procedures  developed,  the  PSES  was  subjected  *0  realistic  test  s' t„a*  ir-'x . 

The  purpose  of  the  test  was  to  obtain  data  for  evaluating  tre  :ec",''u..es  le¬ 
vel  ope-J  during  the  research  period,  whether  -an ^3 1  or  automated.  ‘w  tes* 
situation  involved  the  use  of  the  computer  stored  experimental  lata  poo  1  , 
programs,  and  on-line  computer  hardware  to  *‘un  live  queries .  factors 


specialists  engaged  in  system  development  projects  participated  in  the  test 
program.  With  the  assistance  of  a  user's  guide,  soecially  designed  for  the 
test  program,  the  specialists  accessed  data  from  computer  storage.  Ques¬ 
tionnaires  and  debriefing  period1:  were  used  to  obtain  data  for  eva^ating  the 
PSES  functions.  Included  in  the  ques'ionnai re  were  questions  regarding  the 
effectiveness  of  the  training  period,  the  use  of  the  guide,  difficulties  en¬ 
countered  in  the  retrieval  process,  types  of  data  that  should  be  added  to  the 
experimental  data  pool,  possible  uses  of  the  data  system,  and  the  applicabil¬ 
ity  of  the  system  concept  to  aerospace  system  development  programs.  The  de¬ 
briefings  were  directed  primarily  u  cl ari f i cati on  of  questionnaire  responses. 

Evaluate  Test  Results  and  Pr jpare  Recommendations 

Test  results  were  evaluated  for  possible  immediate  changes  or  recommended 
changes  to  the  PSES  design,  "he  test  results  also  served  to  identify  those 
areas  needing  further  research,  as  shown  by  the  feedback  loops  in  figure  1. 
Changes  and  recommendation  for  changes  are  discussed  in  me  appropriate  sec¬ 
tions  of  this  report.  The  test  procedures  and  evaluation  of  the  results  are 
presented  in: 

Reed,  L.  E.;  Reardon,  S.  E.;  and  Tulley,  A.  T.  Test  and  [valuation  of  Com¬ 
puter  Techniques  for  Handling  Human  Facers  Task  Data  (in  publication!. 

Instructions  for  the  operation  and  maintenance  of  the  PSES  functions  were  pre¬ 
pared  in  user's  and  controller's  guides.  These  instructions  are  reported  in: 

Reardon,  S.  E.  Computerized  Hunan  Factors  "ask  Hat a  handling  Techniques: 
Jser'_s_and  Controller'1  s  Operating  Tj’des,  -TF-pT-CTT v a'5"6 ?!  5 Jf' . 
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SECTION  II 


TASK  DATA  FILE  DEVELOPMENT 


INTRODUCTION 

The  Pilot  Study  Experimental  System  (PSES),  discussed  in  Section  I  of  this 
report,  provides  a  means  to  test  and  evaluate  data  handling  techniques.  It 
also  provides  the  primary  tool  for  determining  the  applicability  of  classifi¬ 
cation  schemes  for  organizing  human  factors  task  information  into  computer 
acceptable  form,  and  for  determining  the  adequacy  of  vocabulary  controls 
that  must  be  imposed  on  the  data.  Research  that  led  to  the  development  of 
data  classification  schemes  for  the  PSES  was  reported  by  Potter  et  al .  (1966). 
An  advanced,  but  untried,  classification  scheme,  is  oresented  in  Section  VI 
of  this  report.  The  development  of  vocabulary  controls  was  reported  in  Oiler 
(1967)  and  in  Section  V  of  this  renort. 

This  section  discusses  the  development  of  an  experimental  data  pool  for  PSES 
test  and  evaluation  exerr'ses.  Two  subjects  are  discussed:  (1)  the  selection 
and  organization  of  sample  task  data  for  the  PSES,  and  (2)  the  preparation 
of  data  for  computer  storage.  The  first  subject  covers  the  selection  of 
aerospace  systems,  selection  of  data  types,  identification  of  classes  of 
data,  and  selection  of  sample  data  for  input  to  the  PSES.  Classification 
structures  and  vocabulary  controls  are  discussed  briefly  in  context  with  the 
total  development  of  the  experimental  data  pool  for  the  PSES.  The  second 
subject  includes  all  processes  necessary  for  converting  the  selected  samole 
data  into  a  format  acceptable  to  computer  storage  and  processing. 


SELECTION  AND  ORGANIZATION  OF  DATA 

Figure  5  illustrates  the  overall  activities  that  led  to  the  selection  of  a 
representative  sample  of  data  for  input  to  the  PSES.  The  activities  begin 
with  the  selection  of  serospace  systems  to  be  considered  in  the  research  and 
terminate  with  the  selection  and  organization  of  data  to  be  prepared  for 
computer  storage. 


Selection  of  Systems 

Data  handling  techniques  cannot  be  developed  and  tested  in  a  vacuum.  To  more 
realistically  fulfill  the  requirements  listed  in  the  preceding  section  (see 
page  4),  aerospace  systems  in  early  stages  of  design  were  selected  for  this 
study.  The  following  criteria  governed  the  selection  of  systems: 

•  The  systems  should  be  in  early  stages  of  development  so  that  +he 
evolutionary  process  of  data  generation  and  use  can  be  considered. 

•  The  systems  must  contain  a  personnel  subsystem  or  life  science  urogram. 

•  The  systems  must  contain  development  programs  that  require  the  generation 
of  task  information. 
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Figure  5.  Development  of  PSES  Data  Base  Content 


•  The  systems  should  be  representative  of  those  developed  for  the  government, 
e.g.,  space  systems,  aircraft  systems,  missile  systems. 

To  be  effective,  data  handling  techniques  must  be  applicable  to  different  types 
of  aerospace  systems.  The  research  must  determine  whether  or  not  a  data  sys¬ 
tem  can  be  developed  that  processes  information  generated  from  totally  dif¬ 
ferent  types  of  aerospace  systems  and  still  provide  for  accessing  data  across 
systems.  Thus,  rather  than  select  a  sample  of  similar  types  of  systems,  e.g., 
aircraft  systems,  or  subtypes  of  similar  sysums,  e.g.,  fighters  or  trainers, 
three  different  types  were  chosen: 

Aircraft  sys^m-Heavy  T-ansport  Aircraft  (C-5A) 

Command  and  control  system-Airborne  Launch  Control  Center  (ALCC) 

Space  booster  system- Saturn  V,  Stage  IC  (SV-IC) 

At  the  time  of  selection,  all  three  systems  were  in  various  stages  of  early 
development,  and  all  required  some  form  of  human  factors  effort  in  their  de¬ 
velopment  process. 

Selection  of  Human  Factors  Data  Forms 

To  be  useful,  a  data  system  must  be  capable  of  processing  information  in  all 
its  various  forms  and  at  any  level  of  detail.  This  requirement  is  particu¬ 
larly  important  to  human  factors  information,  since  the  forms  of  the  data  are 
as  varied  as  the  ways  they  are  reported  and  used.  The  research  prob’^m  was 
to  select  an  aggregate  of  human  factors  data  containing  these  characteristics. 
In  their  report  of  the  preliminary  research,  Hannah  and  Reed  (1965)  con¬ 
cluded  that  human  factors  task  data  constitute  a  large  body  of  information 
used  throughout  system  development  and  that  the  use  of  this  information  is 
essential  to  the  system  envelopment  process.  Task  dat2  are  used  in  some  way 
throughout  every  stage  of  system  development,  are  often  used  repeatedly, 
e.g.,  the  same  data  may  be  used  to  generate  training  requirements  and  man¬ 
ning  estimates,  and  contribute  to  a  large  variety  of  aerospace  system  pro¬ 
ducts.  Figure  6  illustrates  $o..«  of  the  various  uses  made  of  task  and  task 
analysis  data  in  Air  Force  Personnel  Subsystem  (PS)  programs.  Furthermore, 
the  forms  that  task  data  take,  e.q.,  narrative,  quantitative,  and  the  for¬ 
matting  structure  of  these  data,  e.g.,  fixed  formats,  graphs,  drawings,  are 
representative  of  the  total  personnel  subsystem  data  forms  and  formats  used 
in  aerospace  system  development  programs. 

The  procedures  and  requirements  for  generating  task  information  vary  from 
system  to  system.  Task  information  varies  considerably  in  both  content  and 
form,  depending  on  the  system  development  program  problems,  the  system  being 
analyzed,  the  p*>Hod  in  the  system  life  cycle,  and  on  the  idiosyncrasies  and 
needs  of  the  data  generator.  The  research  problem  was  tn  '  group  of 
task  data  from  each  of  the  three  aerospace  systems.  The  to-  ..  selected 
had  to  be  representative  of  the  total  task  data  generated  on  eaui  system  and 
had  to  Form  a  coherent,  group  with  regard  to  uses  in  the  three  aerospace  sys¬ 
tems.  That  is,  the  data  may  vary  in  form  and  content,  but  their  uses,  e.g., 
generation  of  personnel  and  training  requirements,  maintenance  procedures, 
job  analysis,  must  be  similar.  Appendix  I  contains  illustrative  sample  for- 
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Figure  §.  Uses  of  Task  Data  in  System  Development  Programs 


mats  used  by  originating  aerospace  system  contractors  for  recording  task  In¬ 
formation  on  the  ALCC  and  C-5A.  These  include  formats,  such  as  task  analysis 
worksheets  (TAWS),  Requirements  Allocation  Sheets  (RAS),  time-line  analysis  (TL), 
engineering  and  other  drawings  (DR),  task  listings  in  Qualitative  and  Quanti¬ 
tative  Personnel  Requirements  Information  (QQPRlj  documents,  and  other  engineering 
data  (OED) .  A  large  sample  of  these  formats,  containing  operational  and  main¬ 
tenance  task  information  on  the  cnree  systems  ,  was  analyzed  foi  content  and  ap¬ 
plicability  to  computer  storage  in  accordance  with  the  requirements  listed  on 
pages  4  through  6  of  this  report. 

Isolation  of  Major  Data  Elements 

An  important  consideration  in  applying  information  system  techniques  to  data 
handling  problems  is  the  determination  of  the  characteristics  of  the  data  to 
be  handled  by  the  system.  Factors  involved  in  gaining  a  complete  understand¬ 
ing  of  the  data  include  their  diversity,  application,  environment,  content, 
life  cycle,  and  the  significant  phases  in  their  generation  and  use.  Since 
the  data  system  must  adhere  to  multiple  user  requirements,  the  research  must 
determine  if  a  data  structure  can  be  developed  for  diverse  types  of  aero¬ 
space  systems  that  must  rely  heavily  on  common  storage  and  indexing  tech¬ 
niques.  The  need  for  a  common  method  of  labeling  and  defining  data  is  ap¬ 
parent  if  the  automation  goals  of  the  research  are  to  be  met.  Currently  there 
are  no  precedents  for  a  user-oriented  information  system  that  includes  such 
a  large  assortment  of  data  types  generated  in  sunport  of  many  system  devel¬ 
opment  programs  that  establishes  information  handling  techniques  on  a 
factual  rather  than  a  document  level. 


The  *irst  need  was  to  create  an  organi zational  framework  that  accommodates 
task  data  generated  in  support  of  different  aerospace  system  development  pro¬ 
grams.  To  allow  the  user  to  access  data  across  systems,  information  common 
to  all  systems,  as  well  as  system  specific  information,  had  to  be  identified, 
labeled,  and  defined.  The  procedure  used,  and  reported  by  Potter  et  al . ( 1 966 ) , 
was  based  on  the  derivation  of  common  data  elements.  A  data  element,  in  this 
context,  is  a  label  that  represents  a  generic  class  of  information  containing 
any  number  of  subordinate  classes  of  data.  The  defined  elements  must  accom¬ 
modate  a  wide  variety  of  data  and  must  serve  as  the  common  pivotal  point 
for  conducting  detailed  content  analysis  of  specific  data  items.  Data  generated 
in  support  f  the  three  systems  selected  for  this  research  were  used  to  derive 
a  list  of  data  elements.  The  first  step  was  accomplished  by  comparing  the 
major  information  content  of  the  dat  formats  (see  Append! <  II).  This  exercise 
produced  the  following  ten  elements  presented  with  their  definitions 


Data  Element 


Def ini tion 


1 .  Object  System 


The  designator  of  a  specific  aerospace  system. 


2.  Mission 

Information 


A  specific  operational  maintenance  profile  or  pro¬ 
file  segment  for  the  specified  object  system. 


3.  System 

Information 


Specific  data  relating  to  the  hardware  and  soft¬ 
ware  required  to  accomplish  the  specified  mission 
or  segment. 
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4.  Performance 
Description 

5.  Performance 
Characterlstecs 


6.  Hardware 

Characteristics 


7.  Personnel 
Description 


8.  Time 
Information 

9.  Remarks 


10.  Source 

Identifiers 


Specific  data  relating  to  the  level  of  detail  to  be 
included  in  the  related  performance  descriptions 

Specific  data  relating  to  the  man/machine,  and  man/ 
ma"  interfaces  and  duties  required  to  accomplish  the 
specified  mission  or  segment 

Specific  data  regarding  the  human  engineering  char¬ 
acteristics  of  the  hardware  required  to  accomplish 
the  specified  mission  or  segment 

The  job  title  and/or  Air  Force  specialty  code  of 
personnel  required  in  the  specified  acti vi ty--spe- 
cial  skills  or  knowledge  required  of  the  performer 
are  also  noted 

Specific  data  regarding  performance  or  mission  re¬ 
lated  time  values 

Miscellaneous  comments  and  remarks  necessary  to 
explain  any  material  contained  in  other  data  ele¬ 
ments 

Specific  data  regarding  the  origin  and  author,  date 
of  completion  or  revision,  references  used  by  the 
generators,  and  security  or  proprietary  restrictions 

Data  Item  Analysis 


The  ten  major  elements  represent  classes  of  data  conmon  across  the  C-5A,  ALCC, 
and  Saturn,  and  represent  the  most  general  level  of  information  content  for 
these  there  systems.  The  next  step  was  to  carry  the  content  analysis  to  the 
data  item  level,  e.g.,  particular  statements  of  human  performance,  hardware, 
special  skills,  and  knowledge.  Thus,  the  approach  was  to  first  classify  task 
data  i.ito  a  generic  structure--elements--then  provide  for  subciasses--data 
items--1n  accordance  with  the  requirements  for  using  data.  This  approach  in¬ 
volved  specifying  the  level  of  detail  needed  to  access  selectively  individual 
data  itams  according  to  user's  needs.  The  primary  objectives  of  the  data 
item  content  analysis  were  as  follow: 


•  Identification  of  Common  Data  Items 

To  provide  a  standard  frame-oT-reference  for  retrieving  data  within  and 
across  aerospace  systems,  it  is  necessary  to  isolate  tnose  data  items  com 
mon  to  all  systems.  The  ways  in  which  data  are  referred  to  vary  from 
system  to  system  and  from  analyst  to  analyst.  The  same  information  may 
take  the  form  of  numbers,  be  described  In  narrative  form,  or  be  coded. 

For  example,  there  Is  no  standardized  method  for  defining  or  describing 
personnel  hazards  involved  in  the  performance  of  tasks.  One  analyst  may 
place  the  degree  of  hazards  involved  in  a  particular  task  on  a  rating 
scale,  while  another  analyst  simply  describes  hazards  in  narrative  form. 
In  other  instances,  personnel  hazard  data  may  be  embedded  in  other  cate- 
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qories  of  information,  such  as  task  criticality,  personnel  safety,  criti¬ 
cality  to  mission  success,  or  actual  accomplishment  of  tasks.  By  choosing 
a  single  term  tc  refer  to  hazard  information,  the  likelihood  of  data  loss 
in  the  retrieval  process  is  reduced.  In  this  way,  the  data  user  is  able  to 
retrieve  hazard  information  across  aerospace  systems.  Where  differences  in 
data  form  exist,  e.g.,  narrative  descriptions  vs.  ratings,  computer  based 
comparisons  of  these  data  cannot  be  made,  e.g.,  retrieve  tasks,  across  sys¬ 
tems,  with  the  highest  hazard  lating.  This  would  require  standardized  tech 
niques  for  generating  and  analyzing  data  in  aerospace  system  development 
programs.  For  the  PSES,  the  user  retrieves  the  data  and  performs  the  de¬ 
sired  comparisons  manually. 

•  Data  Item  Definitions  ,  , 

Each "liata  i'tem  is  defined  in  accordance  with  content  and  usage.  _  Coded  data 
are  defined  and  aerospace  system  names  or  codes  are  identified  in  each  defi 
nition  for  quick  manual  reference  during  retrieval. 

•  Selection  of  Data  Item  Labels 

Upon  completion  of  the  dataTontent  analysis,  standard  labels  tor  common 
data  across  systems  are  selected.  For  example,  data  pertaining  to  hazards 
for  all  systems  are  labeled  HAZARDS,  even  though  the  form  of  data  may  be 
different  for  each  system.  Data  that  are  unique  to  a  system  are  also 
labeled. 

«  Data  Item  Cateqorization  . 

FTategor ullion  scheme  appropriate  to  each  data  item  is  selected  and 
classes  of  related  data  items  are  grouped  into  the  appropriate  data  ele¬ 
ment,.  The  categorization  scheme  selected  is  determined  by  the  data  item 
characteristics  and  content.  A  variety  of  categorization  schemes  may  be 
required  to  best  organize  the  data.  For  example,  certain  data  are  amen¬ 
able  to  hierarchical  arrangements,  while  others  are  best  arranged  in  al¬ 
phabetical  order  or  by  key  terms. 

9  Identification  of  Data  Item  Characteristics 

THeTh aTa  ct  e r i sties ~6T~tKe  Information  contained  in  each  data  item  are 
defined.  The  characters,  e.g.,  alpha,  numeric,  symbolic,  or  combinations 
of  these;  and  make-up,  e.g.,  number  of  numeric  digits,  maximum  number  of 
alpha  characters,  number  of  lines  of  narrative,  for  each  data  item  are 
identified. 

The  data  item  analysis,  ported  in  detail  by  notter  et  a  1 . ( 1 966 ) ,  generated 
27  ALCC  data  items,  35  L-bA  data  items,  and  28  Saturn  data  items  as  listed  in 
Table  I.  Results  of  the  data  content  analyses  for  the  three  aerospace  sys¬ 
tems  are  presented  in  Appendix  I T. ,  along  with  statements  about  the  data 
sources.  Data  item  (computer  element)  definitions  are  presented  in  Appendix 
III. 

Sole ct ior.  of  Data  for  the  PSES 

The  total  amount,  of  human  factors  task  data  generated  on  any  one  aerospace 
system  development  program  is  unquestionably  large  and  unwieldy.  The  three 
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System  Unique  Data  I  terns 


systems  selected  for  this  research  are  no  exception.  To  facilitate  the  re¬ 
search  process,  the  experimental  data  pool  for  the  PSES  was  kept  modest  in 
size.  Technically,  nothing  is  gained  by  continuously  loading  an  experimental 
data  pool.  Howe'er,  data  for  PSES  experimentation  were  representative  of  the 
total  task  data  generated  for  systems  in  the  early  acquisition  phase.  The 
central  block  in  figure  5  shows  the  mission  phases  for  each  system,  the  num¬ 
ber  of  tasks  selected  for  each  mission  phase,  and  the  sources  from  which  data 
were  obtained. 

The  data  selected  from  AL.CC  included  operational  and  flight  maintenance  task 
information.  Although  the  AlCC  is  a  subsystem  to  a  larger  system,  task  data 
concerned  with  the  interface  with  the  larger  system  were  included  when  nec¬ 
essary  to  specify  ALCC  tasks.  The  maintenance  data  selected  were  limited  to 
in-flight  and  flight  line  maintenance;  no  field,  or  depot  level  maintenance 
data  were  included. 

Sample  operat;onal  and  maintenance  task  data  were  selected  from  C-5A  documents. 
The  operational  data  consisted  of  tasks  performed  by  the  flight  crew  on  a  com¬ 
plete  mission--preflight  through  postflight.  Maintenance  data  consisted  of 
turnaround  and  periodic  tasks,  and  of  a  selection  of  field  and  organizational 
level  maintenance  tasks,  including  component  level  detail  required  to  diag¬ 
nose  and  correct  faulty  subsystems.  No  depot  level  maintenance  tasks  were 
included. 

The  Saturn  data  consisted  entirely  of  maintenance  operations,  including  re¬ 
pair,  remove  and  replace  tasks  to  the  individual  part  level  for  sequential 
operations.  Sequential  operation  consisted  of  maintenance  loops  for  the 
Saturn  Launch  Vehicle  Countdown. 

Data  Organization 

The  organization  of  data  for  storage  is  fundamental  to  the  development  of  any 
computer  technique  for  handling  tas*  information.  The  data  organization  must 
be  responsive  to  the  retrieval  needs  of  users  (see  Section  I,  page  2). 

Potter  al.(1966)  indicated  that  in  some  data  systems  simple  organiza¬ 
tional  schemes  are  adequate.  For  example,  bibliographic  data  are  often  or¬ 
ganized  by  subject  or  title;  associated  data,  such  as  publication  author, 
and  keywords  are  all  linked  or  grouped  with  primary  reference  points,  e.g., 
subject.  Searcnes  are  made  using  the  subject  as  the  prime  search  key  and  as¬ 
sociated  data  are  thus  retrieved  with  refe  ence  to  this  primary  key.  More 
complex  organizational  schemes  are  needed  when  the  requirements  to  retrieve 
involve  a  higher  level  of  selectivity.  A  greater  degree  of  depth  is  needed  if 
many  subassociaticns  are  implied  In  the  data,  e.g.,  handling  task  data  on  a 
factual  level.  The  data  can  be  subdivided  into  many  hierarchical  levels  of 
detail,  which  together  form  a  condition  for  data  retrieval.  For  example,  a 
task  statement  (a  particular  level  of  detail)  may  be  '•ivided  in  the  verb 
and  noun,  and  each  task  may  be  further  divided  into  several  categories,  such 
as  time,  position,  equipment  and  criticality.  The  computer  software  tech¬ 
niques  for  handli'v,  data  in  hierarchical  arrangements  are  oiscussed  in  Sec¬ 
tion  II!,  page  33. 
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A  second  problem  in  the  development  of  a  fact  ret^eva  1  system  is  *se  selec¬ 
tion  of  a  particular  data  item  under  which  all  other  data  may  be  organized 
(a  computer  entry).  Implicit  in  the  se’ection  of  a  data  item  is  the  level  of 
detail  necessary  for  selective  retrieval.  The  data  item  selected  for  the  PSES 
experimental  data  pool  was  the  task--statements  that  describe  human  actions 
in  aerospace  system  operations  and  maintenance.  All  other  information  either 
Identifies  the  task,  e.g.,  the  system,  the  mission  phase  under  which  the  task 
is  performed,  entry  dates;  or  describes  the  task  in  terms  of  associated  data, 
e.g.,  time  to  perform,  hardware  required,  task  criticality.  For  the  experi¬ 
mental  data  pool,  items  1  through  10  in  Table  I  identify  the  ALCC,  C-5A, 
and  Saturn  data  and  items  12  through  35  describe  the  task. 

The  data  values  (information  content)  that  identify  and  describe  a  task  are 
grouped  as  one  entry  to  the  experimental  data  pool,  as  illustrated  in  figure  7. 
Each  of  the  items  (categories)  represented  by  the  blocks  in  the  figure  con¬ 
tains  one  or  more  data  values  that  identify  and  describe  a  single  task.  Fig¬ 
ure  8  shows  how  entries  are  grouped  for  the  computer  data  base  (the  group 
of  date  elements  under  which  data  values  are  organized  for  computer  storage). 
For  the  experimental  data  pool,  the  data  items  shown  in  Table  I  are  identical 
to  the  computer  data  elements  that  form  the  data  base  (see  Section  III).  Typ¬ 
ical  data  values  for  some  of  the  data  are  shown  in  figure  8.  Note  that  the 
hierarchical  arrangement  of  the  data  is  maintained  through  repetition  of  data 
values.  Thus,  more  than  one  task  appears  under  a  single  mission  phase  and 
mission  segment  to  allow  the  user  to  access  data  at  either  level  of  detail. 

The  data  values  that  describe  the  task  are  unique  to  each  task. 

Ideally,  the  need  for  accessing  data  across  all  aerospace  system  (see  item  9, 
page  5)  should  result  in  the  development  of  a  single  data  base.  This  would 
provide  the  user  with  a  capability  to  retric-e  information  from  one  or  an\ 
number  of  aerospace  systems  with  a  single  computer  query.  The  creation  of  a 
single  data  base  might  have  been  accomplished  by  adding  a  data  item  called 
SYSTEM  to  the  data  base  elements.  This  item  would  have  then  served  as  a 
condition  for  retrieval.  Data  items  unique  to  particular  systems  would  have 
been  coded  to  designate  them  as  empty  cells  on  entries  for  other  systems. 
However,  the  need  for  protecting  data  having  security  classification  and/or 
proprietary  status  (see  item  11,  page  5)  requires  that  the  integrity  of  eJch 
aerospace  system  data  base  be  maintained.  Access  to  the  data  system  must  be 
rigidly  controlled  to  enforce  the  provisions  of  security  and  to  protect 
proprietary  infoi  >ation.  To  satisfy  this  requirement,  three  separate  data 
bases,  one  for  each  aerospace  system,  were  created  for  the  PSES.  Acress  to 
each  is  through  the  aerospace  system  name,  e.g.,  ALCC.  The  technique  for 
selectively  accessing  data  from  each  of  the  three  data  base  contents  is 
identical . 

The  creation  of  a  separate  data  base  for  each  of  the  three  aerospace  systems 
prevents  access  of  information  across  systems  in  a  single  query.  Since  the 
organization  of  data  is  identical  for  each,  qualified  users  can  retrieve  data 
across  systems  by  accessing  each  data  base  separately  and  repeating  the  same 
query  statement  on  each.  That  the  user  must  query  each  data  base  separately 
to  access  data  across  aerospace  systems  does  not  present  an  appreciable  prob¬ 
lem,  but  the  process  is  inconvenient  and  time  consuming.  To  ai  the  user,  a 
fourth  data  base  was  created,  called  INDEX.  This  data  base  contains  reference 
points  to  data  contained  in  Lhe  three  aerospace  sy, ten  data  bases.  The  com¬ 
puter  elements  are  similar  to  the  system  data  bases,  cut  only  ;  lique  values 
for  the  ALCC,  C-5A,  and  Saturn  are  stored.  Thus,  while  a  particular  A ESC 
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code  try  appear  numerous  times  in  the  ALCC  data  base  (depending  on  the  number 
of  tasks  assigned  to  that  AF SC),  INDEX  contains  only  one  reference  point  to 
that  AFSC,  This  technique  permits  the  user  to  determine,  in  one  query,  if  the 
particular  AFSC  in  question  has  also  been  assigned  to  other  systems.  For  the 
PSES  experimental  data  pool,  a  selected  ninnber  of  data  items  was  used  for  the 
INDEX  data  base.  The  data  items  are  shown  in  Appendix  V. 

DATA  PREPARATION  FOR  COMPUTER  STORAGE 


Figure  9  illustrates  the  overall  activities  that  led  to  the  preparation  of  task 
data  for  storage  in  the  PSES.  The  activities  start  with  the  development  of  a 
standard  input  form  and  conclude  with  the  storage  of  data  on  magnetic  tape  and 
disc,  as  preliminary  steps  to  computer  processing  of  the  data. 

Input  Forr~ 

As  described  previously,  task  information  generated  in  support  of  the  three 
systems  exists  in  a  wide  variety  of  physical  formats.  They  range  from  free 
formatted  analysis  worksheets  and  drawings  to  highly  formatted  forms  (see 
Appendix  I),  To  assist  in  the  extraction  and  organization  of  data,  a  common 
format  was  required  to  record  the  data.  A  review  of  the  data  formats  of  the 
Air  Force,  NASA,  and  various  contractors  was  conducted  to  determine  whether 
an  existing  format  could  be  used  as  a  standard  for  the  research.  The  formats 
examined  did  not  provide  the  flexibility  necessary  for  recording  data  f—>m  the 
three  systems.  Thus,  a  standard  input  form,  based  on  the  ten  data  elements  on 
page  IS,  was  designed  (see  Appendix  IV).  This  standard  input  form  served  to 
compact  the  data  from  various  locations  in  the  generator’s  system  support 
formats  into  a  central  location,  facilitated  the  conversion  of  data  into  stan¬ 
dard  nits,  e.g.,  time  into  minutes  and  hundredths  of  minutes,  and  reduced 
the  time  required  to  convert  the  data  into  computer  acceptable  form-key¬ 
punching.  The  information  recorded  on  each  form  was  based  on  the  data  items 
shown  in  Appendix  V. 

The  process  of  extracting  information  from  original  formats  was  regarded  as  a 
clerical  operation,  in  contrast  to  the  generation  of  data.  Undergraduate 
university  students  assisted  in  this  operation.  An  informal  training  program 
was  prepared  to  acquaint  the  students  w'th:  (1)  the  content  and  use  of  human 
factors  task  information  with  which  they  were  to  work,  (2)  instructions  for 
using  the  standard  input  form,  and  (3)  the  guidelines  for  extracting  informa¬ 
tion  from  system  formats.  The  data  extraction  guidelines  for  the  three  systems 
are  in  Appendix  VI. 


Quality  Control 

After  data  were  transferred  to  the  standard  input  form,  these  forms  were 
examined  for  correctness.  Spelling,  abbreviations,  and  grammatical  correct¬ 
ness  were  verified.  If  certain  items  of  data  were  missing  from  the  input 
forms,  they  were  checkeo  against  the  original  data  source  to  determine  if 
particular  items  of  data  were  indeed  unavailable.  Terminology  was  standardized 
as  much  as  possible,  particularly  in  the  area  of  hardware  information.  For 
example,  the  same  hardware  may  have  been  designated  "copilot  instrument  panel", 
"copilot's  instrument  panel",  and  "CP  instrument  panel".  All  representations 
of  time  were  converted  into  minutes  and  hundredths  of  minutes. 
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qure  9.  Data  Preparation  For  Storage 


Vocabulary  Control 


The  final  step  before  keypunching  the  data  was  to  determine  if  the  descriptors 
in  the  task  statements  adhered  to  the  definitions  in  the  controlled  vocabulary 
and  the  rules  governing  word  usage  described  by  Oiler  (1967).  The  rules  and 
standardized  definitions  helped  to  minimize  the  inconsistencies  in  meaning  of 
all  terms,  control  the  proliferation  of  syr.  lyms,  reduce  the  loss  of  data  in 
the  retrieval  process,  and  avoid  the  nclusion  of  jargon  in  the  data  base. 

Keypunching 

After  all  corrections  were  made  to  the  input  forms,  their  contents  were  trans¬ 
ferred  to  standard  80-column  IBP  cards  to  be  loaded  into  LUCID,  the  information 
storage  and  retrieval  system  used  fo1*  PSES  (see  Section  III).  General  for¬ 
matting  rules  for  data  to  be  loaded  into  a  LUCID  data  base  are  presented  in 
Appendix  VII. 

Edi ting  Routines 

The  single  field  number  and  value  method  of  keypunching  (see  Appendix  VII, 
oaqe  141)  was  used  for  the  PSES  data  bases  and  several  short  computer  programs 
were  written  to  aid  in  the  edition  of  the  data.  These  programs  made  a  check 
for  matching  parentheses,  missing  field  numbers  and  missing  entry  terminators. 

Cards  to  Magnetic  Tape 

After  all  preliminary  editing  of  the  data,  the  cards  were  prestored  on  mag¬ 
netic  tape.  This  task  was  performed  on  an  IBM  1401  computer  wt  s  the  data 
were  stored  at  a  density  of  556  bits  per  inch.  (This  density  is  required  for 
use  by  the  IBM  AN/FS  Q-32  computer,  on  which  LUCID  operates.)  The  prestored 
tape  was  printed  for  use  in  further  editing  and  then  sent  to  the  Q-32  computer 
room  at  the  System  Development  Corporation  facility  at  Santa  Monica,  Califor¬ 
nia. 

Disc  Storage 

In  the  Q-32,  the  data  on  the  prestored  tape  were  transferred  to  disc  storage 
by  th''  11  of  an  on-line  editing  program.  Further  edition,  where  required,  was 

then  h  rmed.  At  that  time,  the  data  were  ready  to  be  used  by  LUCID  (see 

Secti or  III). 


REORGANIZATION  OF  THE  DATA  POOL  FOR  TPMS 

System  Development  Corporation  is  developing  the  Time-Shared  Da*'-’  Management 
System  (TOMS)  to  operate  on  the  IBM  360  computer  (see  Section  III).  Partly 
due  to  recommendations  made  by  Potter  et  al.  (1966)  for  using  TDMS  as  a 
further  extension  of  the  research  on  data  handling,  and  partly  as  a  result  of 
the  PSES  tests,  the  data  pool  was  reorganized  into  a  structure  that  took 
advantage  of  the  increased  retrieval  capabilities  offered  by  TDMS. 
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Data  Organization 


Other  changes  were  made  as  a  result  of  limitation':  discovered  in  the  organi¬ 
zation  of  the  PSES  data  pool.  Use  was  made  of  the  hierarchical  structuring 
capability  of  TDMS.  This  capability  enables  the  user  to  qualify  and  retrieve 
data  at  a  finer  level  of  detail.  To  accomplish  this,  the  computer  data  ele¬ 
ment  previously  known  as  the  TASK  was  eliminated  entirely.  The  name  TASK  was 
retained  as  the  heading  oi  a  group  of  elements  that  describe  the  man/machine 
action  identified  i,,  the  TASK  iTATEMENT.  All  tasks  performed  within  speci¬ 
fied  segments  of  time  were  grouped  in  one  entry  and  were  identified  by  the 
mission  phase,  mission  segment,  and  time  segment  in  which  they  occur.  Ap¬ 
pendix  VI II  contains  the  changed  or  revised  organization  and  Appendix  IX  con¬ 
tains  the  definitions  of  the  revised  data  elements. 

Data  Preparation 

Only  C-5A  data  were  reorganized  for  TDMS  to  illustrate  the  manner  in  which  re¬ 
organization  could  be  conducted.  The  data  were  transferred  from  the  original 
input  forms  to  a  modified  input  form.  Additional  reference  was  made  to  the 
original  data  sources  whenever  questions  arose  about  such  items  as  the  be¬ 
ginning  and  ending  times  of  each  task*  After  all  data  were  transferred  to 
the  new  forms,  they  were  keypunched,  with  minor  exceptions,  in  accordance  with 
the  rules  presented  in  Appendix  VII.  The  cards  were  then  prestored  on  mag¬ 
netic  tape  which  were  then  ready  for  processing  by  TDMS. 


SECTION  III 


APPLICATION  OF  COMPUTER  SOFTWARE  TECHNIQUES  TO  STORAGE  AND  RETRIEVAL 
INTRODUCTION 


Research  into  the  application  of  computerized  techniques  to  the  processing 
of  human  factors  task  data  (Potter  et  al.,  1966)  led  to  the  establishment  of 
a  number  of  requirements  for  a  da  a  handling  system  (see  Section  I,  pages  A 
and  5)  and  to  the  conceptualization  of  such  a  system.  The  proposed  experi¬ 
mental  system  was  not  required  to  possess  all  of  the  characteristics  of  ^he 
envisioned  operational  system,  but  was  required  to  be  similar  enough  in  oper¬ 
ation  and  capability  in  the  major  processing  area  to  permit  meaningful  evalu¬ 
ation  of  the  techniques  used. 

The  heart  of  such  an  experimental  system  is  the  information  storage  and  re¬ 
trieval  processing  necessary  to  organize  and  maintain  data  within  computer 
storage  and  to  retrieve  the  data  in  accordance  with  the  requirements.  Be¬ 
cause  of  the  research  characteristics  of  the  PSES,  it  was  not  practical  to 
develop  or  use  highly  specialized  information  storage  and  retrieval  tech¬ 
niques  that  could  not  respond  to  changes  in  requirements  as  research  pro¬ 
gressed.  Consequently,  existing,  general  purpose  data  handling  techniques 
were  recommended  to  provide  the  information  storage  and  retrieval  capability 
for  the  PSES.  Two  specific  generalized  systems  were  recotnnended .  The  first 
of  these  systems  is  LUCID  (Language  Used  to  Communicate  Information  System 
Design)  (Robert  E.  Bleier,  System  Development  Corporation,  TM-26’4/100/00) . 

The  second  and  nv.c*  advanced  system  is  TOMS  (Time-Shared  Data  Management 
System)  which  is  currently  under  development  (Vorhaus  and  Wills,  1967). 

The  LUCID  system  is  described  in  detail  in  related  research  documentation 
(Tulley  and  Meyer,  1967).  Briefly,  LUCID  is  a  generalized  data  management 
system  developed  by  System  Development  Corporation  (SDC)  under  the  sponsorship 
of  the  Advanced  Research  Projects  Agency  (ARPA).  It  operates  within  the  time- 
shared  environment  of  a  large-scale  digital  comDUter,  the  1 BM/AN/ FSQ-32 , 
located  at  the  ^DC  facility  in  Santa  Monica,  California. 

Many  elements  of  LUCID  are  being  refined  and  expanded  into  TOMS,  also  under 
development  by  SDC.  Though  TDMS  is  being  initially  designed  for  the  Model 
65  IBM  S/360  computer,  the  system  can  be  adapted  to  increasingly  sophisti¬ 
cated  versions. 

Both  LUCID  and  TDMS  provide  an  off-the-shelf  computerized  capability  for 
application  to  problems  that  are  not  necessarily  related  but  that  share  com¬ 
mon  processing  requirements.  The  requirements  center  about  the  need  to  organ¬ 
ize,  maintain,  retrieve,  and  present  large  volumes  of  data.  Use  of  either 
system  does  not  require  knowledge  of  computer  or  programing  techniques,  and 
permits  the  development  of  a  data  handling  capability  in  a  minimum  of  time 
and  training.  This  is  accomplished  without  the  cost  of  designing,  developing, 
implementing,  and  maintaining  a  special-purpose  system. 
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APPLICATION  OF  LUCID  AND  TDMS 


The  application  of  LUCID  and  TDMS  to  the  handling  of  human  factors  task  data 
within  the  frameworks  of  PSES  is  viewed  from  the  standpoint  of  the  overall 
requirements  of  the  operational  data  handling  system  described  by  Potter  et 
al.(196o).  Of  the  requirements  defined  in  Section  I,  pages  4  and  5,  those 
that  relate  directly  to  information  storage  and  retrieval  require  that  the 
system: 

•  Provide  for  the  storage,  updating,  and  retrieval  of  human  factors  task  data 

•  Accept  and  output  data  in  a  form  approaching  user-terminology 

•  Provide  a  user-oriented  query  language 

•  Provide  a  data  bank  structure  flexible  enough  to  al'ow  for  future  expan¬ 
sion  and  inclusion  of  additional  data  elements 

•  Provide  a  data  bank  capable  of  frequent  updating 

•  Be  capable  of  retrieving  similar  information  generated  in  support  of  dif¬ 
ferent  aerospace  systems 

•  Be  capable  of  selectively  retrieving  data  elements  by  qualifying  them  with 
other  data  elements 

•  Provide  the  user  freedom  in  specifying  the  format  of  outputs 

Each  of  these  requirements  is  considered  in  the  discussion  that  follows. 

Storage  and  Retrieval 

The  successful  application  of  either  LUCID  or  TDMS  to  the  storage  and  re¬ 
trieval  functions  of  PSES  depends  upon  adequately  defined  and  organized  infor¬ 
mation  to  be  processed.  Information  selected  for  PSES  consists  of  a  pool  of 
operational  and  maintenance  task  data  generated  in  support  of  the  ALCC,  C-5A, 
and  Saturn  development  programs.  The  general  information  content  of  the  data 
pool  is  described  in  the  previous  section  of  this  report. 

Once  the  data  have  been  defined  and  an  organization  established,  the  infor¬ 
mation  must  be  input  to  the  LUCID  or  TDMS  system.  This  is  accomplished  for 
both  LUCID  and  TDMS  by  informing  the  system  of  the  uniquely  identifiable 
data  elements  that  are  to  be  contained  in  the  data  pool,  the  name  to  be  as¬ 
signed  to  each,  the  type  of  information  to  be  contained  in  each,  and  the  re¬ 
lationships  between  elements.  Once  this  has  been  accomplished,  the  functions 
of  storing,  updating,  and  retrieving  information  from  the  experimental  data 
pool  may  be  carried  out.  Complete  indexing  of  data  for  efficient  retrieval 
Is  assured. 

Typical  data  elements  established  for  LUCID  identiiy:  at  what  point  in  a  mis¬ 
sion  a  ask  occurs,  who  performs  the  task,  the  length  of  the  task,  and  the 
equipment  used.  Establishment  of  elements  is  essentially  accomplished  by 
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determining  the  key  task  information  for  the  three  systems.  Although  each  of 
the  systems  contains  similar  overall  categories  of  information  (see  Appendix  II 
and  tne  element  list,  pages  19  &  20),  the  uniquely  identifiable  elements  needed 
to  permit  satisfactory  computer  manipulation  of  the  data  are  not  standard 
across  the  three  systems.  They  vary  in  accordance  with  the  information  content 
of  each  system  and  the  level  of  data  available  for  entry  into  the  experimental 
data  pool.  cor  this  reason  and  to  protect  proprietary  interests  by  preserving 
file  integrity,  three  separate  data  bases  were  established  within  the  experi¬ 
mental  data  pool --one  for  each  system. 

LUCID  penni ts  the  user  to  move  from  data  base  to  data  base  with  ease  and  allows 
the  user  to  apply  the  same  retrieval  techniques  to  each.  Appendix  V  contains 
a  list  of  tne  data  elements  used  to  describe  each  of  the  three  systems.  Ap¬ 
pendix  III  contains  an  alphabetized  list  of  elements  and  their  definitions. 

Only  data  from  the  C-5A  system  were  selected  for  entry  into  TDMS.  The  data 
structure  for  C-5A  was  modified  to  take  advantage  of  hierarchical  structures 
allowed  by  TDMS.  Other  changes  resulted  from  evaluation  of  the  LUCID  data 
structures  (see  Section  II).  Appendix  VIII  is  a  list  of  the  C-5A  data  elements 
for  TDMS.  Appendix  IX  contains  the  definition  of  each  of  these  elements. 

User  Terminology 

Ideally,  the  user  of  a  data  system  should  be  able  to  access  and  receive  infor¬ 
mation  in  his  own  terminology.  Queries  that  must  be  phrasta  or  computer  re¬ 
sponses  that  must  be  interpreted  through  the  use  of  handbooks  or  with  the  as¬ 
sistance  of  a  systems  specialist  defeat  the  purpose  o'  timely  retrieval  of 
information.  For  the  purpose  of  the  research,  user  terminology  is  generally 
considered  to  be  the  terminology  employed  by  the  generators  of  the  task  data 
entered  into  computer  storage.  With  the  exceptions  of  the  standardization  of 
the  vocabulary  used  to  express  various  items  of  information  and  the  conver¬ 
sion  of  all  expressions  of  time  into  minutes,  the  form  of  data  as  received 
is  not  altered  before  entry  into  the  comouter. 

For  the  most  part,  information  required  to  adequately  express  human  perfor¬ 
mance  is  highly  textual  in  format,  e.g.,  phrases  and  sentences,  and  requires 
a  processing  system  that  can  efficiently  store  and  manipulate  large  volumes 
of  alphanumeric  data.  LUCID  and  TDMS  are  especially  efficient  in  terms  of 
manipulating  this  textual  information.  This  enables  a  user  to  qualify  re¬ 
trieval  of  information  with  familiar  terminology  and  to  retrieve  program¬ 
generated  responses  in  a  similar,  readily  interpreted! e  format. 

User-Oriented  Query  Language 

The  purpose  t f  a  user-oriented  query  language  corresponds  closely  ^o  the  ob¬ 
jectives  of  the  preceding  discussion  on  user  terminology.  The  intention  of 
a  user-oriented  query  language  is  to  enable  a  user  to  directly  access  the 
data  pool  without  having  to  consult  a  systems  expert  or  a  detailed  handbook 
regarding  system  operations  and  restrictions.  The  more  closely  the  query 
language  approaches  the  terminology  in  which  a  user  normally  references  his 
data,  the  easier  it  is  for  him  to  use  the  system. 
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LUCID  provides  the  experimental  system  with  a  ouery  language  that  is  easy 
to  use  and  easy  to  learn.  The  vocabulary  consists  of  relatively  few  commands 
and  modifiers,  which  can  be  combined  tc  form  highly  selective  requests  for 
retrieval  of  information,  TDMS  provides  the  same  type  of  language,  though 
It  Is  slightly  more  detailed  because  of  *h e  larger  number  of  operations  TDMS 
can  perform.  Requests  are  entered  to  either  system  on  an  on-line  keyboard 
console,  and  Immediate  on-line  response  is  provided  by  the  retrieval  program. 

When  the  data  elements  were  established  for  each  of  the  data  bases  in  the 
data  pool,  each  element  was  assigned  a  descriptive  name  that  clearly  iden¬ 
tified  the  Information  to  be  contained  in  that  element.  When  formulating 
queries,  these  elements  are  referenced  by  name  to  indicate,  to  the  retrieval 
program,  the  data  to  be  retrieved  and  the  qualifying  to  be  done.  A  formulated 
retrieval  request  is  a  readable,  self-explanatory  statement  For  example,  to 
retrieve  tasks  performed  by  the  navigator  during  preflight  operations  of  the 
C-5A  aircraft  the  query, 

PRINT  TASK  WHERE  (PERSONNEL  TYPE)  EQ  NAVIGATOR 
AND  (MISSION  PHASE)  EQ  (PREFLIGHT  OPERATIONS) 

retrieves  from  the  C-5A  data  base  a  list  of  the  tasks.  The  parentheses  in  the 
query  example  are  required  by  the  LUCID  retrieval  program  to  delimit  names 
of  data  elements  and  data  values  that  require  more  than  one  word  to  ex,  -'ess. 
This  restriction  does  not  exist  in  the  TDMS  retrieval  program.  The  query 
language  for  both  systems  also  provides  a  method  of  using  system-defined 
synonyms  when  formulating  retrieval  requests.  Use  of  the  short  synonym  names, 
usually  two  or  three  characters  in  length,  facilitates  the  entering  of  what 
might  otherwise  be  lengthy  retrieval  requests  through  the  keyboard  of  the  on¬ 
line  console. 


Data  Bank  Structure 


The  requirement  to  provide  an  operational  capability  to  add  and  delete  ele¬ 
ments  of  data  from  the  experimental  data  pool  in  response  to  changing  system 
requirements  is  recognized  as  a  very  real  and  difficult  problem.  Like  up¬ 
dating,  it  requires  a  sophisticated  processing  mechanism,  as  well  as  a  man¬ 
ual  control  mechanism  to  assure  the  proper  and  timely  use  of  the  capability. 
Procedures  must  be  provided,  for  example,  to  assure  that  users  of  the  system 
are  aware  that  a  particular  store  of  data  has  been  restructured.  The  pro¬ 
blems  of  restructuring  in  an  operational  environment  have  not  been  fully  ex¬ 
plored  during  the  current  research. 

Because  of  the  controlled  environment  in  which  the  PSES  is  exercised,  pro¬ 
cedural  control  of  the  restructuring  necessary  for  the  experimental  data  pool 
during  the  course  of  the  research  was  not  a  problem.  The  restructuring  pro¬ 
cess  Itself,  however,  was  extremely  time-consuming  and  involved.  Even 
though  it  was  known  at  the  onset  that  LUCID  did  not  provide  any  automated 
method  of  adding,  deleting,  or  rearranging  elements  of  data  within  the  data 
pool,  the  restructuring  problems  were  considered  minimal.  Some  restructuring 
occurred  as  the  research  progressed  and  it  became  apparent  that  the  magnitude 
of  this  effort  was  clearly  underestimated.  The  procedure  that  must  be  f o 1  - 
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lowed  in  order  to  restructure  any  or  all  of  the  data  pool  is  to  redescribe  the 
data  base  being  restructured  and  to  reenter  all  data  for  that  data  base  into 
storage  in  accorda"^  with  the  new  structure.  In  some  instances,  large  vol¬ 
umes  of  previously  prepared  input  data  had  to  be  completely  redescribed  be¬ 
fore  they  could  be  reentered  into  storage. 

TDMS  is  expected  to  provide  much  more  flexibility  and  ease  of  operation  in  the 
restructuring  of  data.  The  ability  to  add,  delete,  or  modify  elements  in  the 
data  base  will  be  included  in  the  defining  operation  of  TDMS. 

Update 


The  requirement  for  updating  procedures  in  an  operational  data  handling  sys¬ 
tem  has  not  been  explored  in  depth.  Conceivably,  updating  will  be  required 
on  a  nearly  continuous  basis  to  provide  reasonably  current  information  Large 
scale  maintenance  of  data  files  as  opposed  to  selective  on-line  updating  in¬ 
volving  small  changes,  may  be  a  regular  occurrence.  Assuming  that  the  re¬ 
quirements  for  updating  can  be  established  for  an  operational  system,  the 
development  of  procedures  to  govern  the  updating  is,  in  itself,  a  difficult 
task.  In  an  operational  data  system.it  would  be  necessary  to  designate  in¬ 
dividuals  to  assume  the  responsibility  for  the  updating  and  for  deciding  how 
it  should  be  conducted. 

Requirements  for  updating  information  within  the  framework  of  PSES  are  more 
clearly  defined.  Because  of  the  unscheduled  manner  in  which  data  are  re¬ 
ceived  and  made  available  for  entry  into  the  data  pool,  the  experimental  sys¬ 
tem  must  be  able  to  add  small  or  large  volumes  of  new  oata  to  the  pool.  A 
provision  is  also  required  for  the  correction  of  errors  that  are  undetected  at 
the  time  the  data  are  entered  into  storage. 

The  updating  capability  of  LUCID  satisfies  the  requirements  of  the  experi¬ 
mental  system.  An  on-line  updating  function  permits  rapid  correction  of 
errors  and  handles  deletions  and  additions  o'  small  volumes  of  data.  TDMS 
will  (’’'so  provide  an  updating  capability  'i a  a  larger  scale  maintenance  capa- 
bi 1 i ty. 


Cross-System  Retrie v aj 

One  of  the  primary  requirements  of  an  operational  data  handling  system  is  to 
provide  the  capability  of  retrieving  data  from  various  aerospace  systems  con¬ 
tained  in  the  data  pool.  This  particular  capability  requires  that  adequate 
procedures  be  developed  and  imposed  cn  the  data  system  to  assure  that  pro¬ 
prietary  restrictions  are  respected  and  that  only  authorized  personnel  have 
complete  cross-system  access. 

The  framework  of  the  experimental  data  pool  was  created  so  that  system  data 
are  arranged  and  maintained  separately,  each  in  its  own  data  base.  Both  the 
LUCID  and  the  TDMS  retrieval  mechanisms  permit  access  to  one  and  only  one  data 
base  at  a  time.  This  is  not  considered  to  be  a  restriction  but  rather  lends 
itself  to  the  operational  concept  of  controlled  access  to  the  individual  sys¬ 
tem  data  bases.  Since  the  data  pool  for  the  PSES  was  developed  for  experi¬ 
mental  purposes  only,  proprietary  constraints  were  not  imposed  on  the  system. 
Application  of  the  operational  system  -a  would  require  restrictions  on 
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the  use  of  the  various  data  bases. 

Since  LUCID  permits  access  to  only  one  data  base  at  a  ti.ne  coring  retrieval, 
cross-system  queries  must  be  conducted  serially.  This  does  not  present  dif¬ 
ficulties,  provided  the  user  knows  which  data  bases  to  query.  If,  for  exam¬ 
ple,  preflight  tasks  across  all  pertinent  systems  are  to  be  compared. 

It  would  be  helpful  to  select  oi  ly  those  systems  actually  containing  pre¬ 
flight  tasks.  It  would  be  mean'nql?  -  to  pose  oueries  to  totally  unrelated 
bases  during  the  course  of  retrieving  the  desired  data.  order  to  facili¬ 
tate  cross-system  queries,  a  special  index  data  base,  INDEX,  was  developed 
(see  Appendix  V  ).  This  data  base  provides  an  insight  into  the  data  content 
of  the  system  data  bases.  Queries  asked  of  INDEX  usually  result  in  a  list¬ 
ing  of  systems.  For  example,  "What  systems  contain  preflight  tasxs?"  would 
provide  a  list  of  all  qualifying  systems.  The  data  bases  u’n  then  be  queried 
on  an  individual  basis  for  more  detailed  information. 

TDMS  will  operate  like  LUCID,  selecting  cne  data  base  at  a  time.  While  only 
C-5A  data  have  been  converted  to  TDMS  format,  as  more  systems  are  added  to 
this  data  pool,  an  Index  data  base  such  as  the  cne  relating  to  me  LUCID  data 
pool  would  be  established. 


Selective  Retrieval 


It  is  essetial  for  the  user  of  the  operational  task  data  handling  system  to 
be  able  to  adequately  express  his  needs  for  information  to  the  system.  This 
requires:  (1)  the  ability  to  qualify  retrieval  with  certain  conditions,  and 
(2)  the  ability  to  Indicate  the  exact  information  to  be  presented  after 
qualification  has  taken  place.  Either  or  both  of  these  points  can  be  ex¬ 
panded  In  complexity  to  permit  the  retrieval  of  one  or  more  pieces  of  data 
depending  upon  the  existence  of  one  or  more  sets  of  conditions. 

The  LUCID  system  permits  users  of  the  experimental  system  to  qualiiy  on  and 
selectively  present  information  from  any  and  all  data  categories  that  exist 
in  the  data  pool.  Due  to  its  completely  cross-indexed  data  arrangement,  a’l 
data  categories  can  be  qualified  upon  or  ret  ieved  for  output  purposes  with 
relatively  equal  processing.  In  addition,  AND/OR  logic  can  be  used  to  com¬ 
bine  qualifying  expressions.  A  complete  set  of  relational  operators  (equal 
to,  not  equal  to,  greater  than)  and  limited  mathemat-  cal  operators  (sum, 
maximum,  minimum)  are  available. 

TDMS  allows  the  same  options  as  LUCID  with  the  addition  of  certain  mathe¬ 
matical  operators  such  as  exponentiation,  multiplication,  division,  and 
negation.  Although  retrieval  can  be  selectively  accomplished  on  the  basis  of 
data  contained  in  any  and  ail  data  categories  defined  within  the  framework  of 
the  experimental  data  pool,  a  problem  exists  regarding  selectivity.  The 
problem  is  not  directly  related  to  the  retrieval  cabability  of  LUCID,  but 
rather  tc  the  content  and  organization  of  the  LUCID  data  pool  itself.  In 
order  to  expedite  the  preparation  of  data  for  entry  into  the  data  ocol  ,  the 
finer  levels  of  human  performance  were  treated  as  groups  of  actions  necessary 
to  perform  given  tasks  ratner  than  treated  as  individual  actions.  The  result 
Is  that  some  degree  of  selectivity  is  lost  by  the  inabi’ity  to  qualify  on 


these  individual  actions.  The  actions  can  be  retrieved  as  a  group,  bu+  not 
individually.  Inis  limitation  has  been  removed  in  the  data  base  for  TOMS. 
Information  here  may  be  'ieved  to  the  level  of  individual  action. 

User  Controlled  Output  Format 

The  operational  task  data  handling  system  is  intended  to  be  of  use  to  per¬ 
sonnel  representing  a  variety  of  disciplines  and  'kills.  It  is  desirable 
that  each  of  these  individuals  or  groups  be  able  j  control  the  format  of 
retrieved  data  in  order  to  satisfy  their  own  r  rticular  output  requirements. 

A  sophisticated  user-control  led  output  capability  enables  retrieved  data  to 
be  arranged  in  the  form  of  finished  reports,  sunmaries,  etc.,  that  would 
ideally  contain  titles,  headings,  pnge  numbering,  variable  spacing  and  line 
control,  security  classi fi ca ioons  and  so  forth. 

The  LUCID  system  does  net  provide  an  elaborate  formatting  capability.  The 
limited  capability  tnat  it  does  provide,  however,  is  considered  to  be  ade¬ 
quate  for  the  purposes  of  the  PSES.  The  normal  LUCID  output  format  consists 
of  one  or  more  lines  of  retrieved  data  printed  on  the  teletype,  with  infor¬ 
mation  continuing  from  line  to  line.  An  optional  blocked  format  is  alsi  pro¬ 
vided  that  generates  blocked,  tabular  output,  including  headings.  I<:  de¬ 
sired.  retrieval  information  can  be  wr*  r;ten  on  magnetic  tape  for  of’-line 
printing  rather  than  direct  teletype  printing. 

TOMS  contains  a  more  sophisticated  formatting  capability  allowing  the  user  to 
specify  number  of  lines  of  uninterrupted  output,  spacing,  level  of  data  to  be 
retrieved,  and  angled,  columnar,  or  unblocked  output. 

GUIDES  FOR  PSES 


[here  is  a  need  for  some  tool  to  instruct  and  assist  potential  users  in  the 
operation  of  the  PSES.  Such  a  tool  must  contain  all  instructions  necessary 
for  the  operation  of  the  computer  programs  that  comprise  PSES.  An  attempt 
to  meet  this  need  has  been  made  bv  .  ,<•  preparation  of  both  user's  and  a 
controller's  operating  guide  (Reardon,  1968). 

Instructions  for  both  guides  cover  the  following  areas: 


•  Operation  of  remote  terminals 

•  Establishing  communication  wih  each  of  the  computer  programs  of  PSES 

•  Formulating  user  T,puts  to  each  of  the  computer  programs 

•  Interpreting  output  frem  each  program 

•  Recovery  procedures  to  be  taken  when  either  user  or  program  errors  occur 
during  program  operation: 

Both  the  user's  and  the  control ler'  guides  provide  instruction  for  the  oper¬ 
ation  of  the  fo"'  i owing  software  components: 


*  Time-Sharing  System  --  Instructions  are  given  for  establishing  und  main¬ 
taining  r.oftnuni cation  with  the  Time-Sharing  System  via  a  teletype  console. 

*  Querying  the  Data  Base  --  Instructions  are  given  for  data  retrieval  and 
d ala  man  1  puTatfon . 

*  Current  Awareness  --  Instructions  are  given  for  establishing  a  user  profile 
Indicating  data  interests  and  for  matching  the  profile  against  new  or  modi¬ 
fied  data  entering  the  system. 

In  audition  to  the  above  areas,  the  user's  guide  contains  a  section  describ¬ 
ing  the  PSES  data  pool.  This  description  lists  the  data  elements  for  each 
data  base,  defines  each  data  element  and  describes  the  structure  of  each  data 
base. 

The  controller's  guide  contains,  in  addition,  instructions  in  the  following: 

*  Describing  the  Data  Base  —  Instructions  are  given  for  estab1 ishing  a 
description  of  a  new  oata  base. 

*  Loading  the  Data  Base  --  Instructions  are  given  for  loading  data  into  a 
new  data  base. 

*  Updating  the  Data  Base  —  Instructions  are  giver  for  both  small  scale  on¬ 
line  updating  and  for  the  updating  of  large  volumes  of  data. 

Both  guides  are  tabbed  for  easy  use,  tain  many  illustrative  examples,  and, 
where  applicable,  contain  actual  samH  s  of  input  and  output  opposite  these 
examoles . 

c CCURITY  AND  PRIVACY 

Tl»e  problems  of  controlling  classified  and  proprietary  information  have  not 
arisen  in  the  PSE' .  However,  these  problems  would  be  a  source  of  concern  to 
everyone  involved  in  an  operational  system.  For  this  discussion,  ‘-he  term 
"security"  will  be  used  to  refer  to  the  storage,  maintaining,  retrieval,  and 
transmission  of  Department  of  Defense  classified  data  in  an  operational  data 
handling  system.  "Privacy"  refers  to  similar  handling  of  data  which  a  con¬ 
tractor  or  the  government  may  wish  to  protect  from  the  unauthorized  observa¬ 
tion  of  other  contractors  or  users.  For  both  categories  of  information,  di- 
vulgence  could  cause  serious  or  grave  damage,  either  to  the  country  or  to 
private  contractors. 

In  an  operational  data  system,  both  classified  and  private  data  are  to  be 
handled  in  the  same  system;  therefore,  protection  of  both  types  of  data 
must  be  handled  similarly.  Steps  must  be  taken  to  establish,  maintain,  and 
protect  the  desired  security  and  privacy  level  in  the  following  areas: 

*  Physical 


•  Personnel 
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Communications 


*  Software 

Regulations  for  personnel  and  physical  security  are  well  established  by  the 
National  Security  Agency. 

Both  th  .  security  and  privacy  requirements  demand  secure  communication  cir¬ 
cuits.  Various  devices  exist  to  provide  secure  lines  of  communication  be¬ 
tween  remote  terminals  and  the  computer.  Cryptographic  eouipment  is  avail¬ 
able  to  safeguard  against  the  accidental  or  surreptitious  divuigence  of 
information.  Detailed  information  on  such  protection  can  be  obtained  from 
the  National  Security  Agency  if  a  need  for  such  information  can  be  estab¬ 
lished,  e.g.,  a  military  contractor  who  has  an  authorized  need  to  know. 

In  addition  to  providing  for  control  in  the  areas  of  physical,  personnel, 
and  communications  security,  the  following  principles  should  be  observed  to 
obtain  security  and  privacy  with  software: 

*  The  computer  must  operate  under  a  monitor  approved  by  appropriate  authority. 
The  monitor  acts  as  the  overall  guard  cf  the  system,  and  prevents  access 

to  sensitive  information  by  unauthorized  users  and  operators. 

*  The  computer  must,  have  adequate  memory  safeguards  and  privileged  instruc¬ 
tions.  These  are  needed  to  limit  user  programs  that  might  be  damaging  to 
another  user's  program. 

*  The  computer  must  have  appropriate  physical  security  to  prevent  local 
override  of  the  monitor. 

*  All  significant  events  (equipment  malfunctions,  unauthorized  usage,  inter¬ 
ference,  communications  breaks  or  changes)  should  be  recorded  by  the 
computer  and  the  operating  personnel. 

*  Operating  personnel  must  be  cleared  to  che  appropriate  levels. 

*  Every  user  must  be  subject  to  common  discipline  and  authority. 

Men  an  operating  system  involving  classified  and  private  data  is  to  be  es¬ 
tablished,  detailed  investigation  into  these  areas  will  take  place  and  the 
results  of  such  an  investigation  will  be  implemented. 


SECTION  IV 


CURRENT  AWARENESS 


INTRODUCTION 

One  of  the  requirements  of  an  operational  data  handling  system  (Section  I, 
page  4  )  is  that  such  a  system  must  provide  for  current  awareness  notifica¬ 
tions  to  qualified  users.  Notifications  would  enable  the  user  of  the  system 
to  remain  aware  of  the  current  status  of  data  of  interest  to  him  without 
havino  to  continuously  query  the  data  base. 

A  current  awareness  function  notifies  the  user  whenever  data  of  particular 
interest  to  him  are  modified  or  when  new  data  in  his  area  of  interest  are 
entered  into  the  system  data  pool.  Areas  of  interest  are  expressed  by  con¬ 
trolled  word  lists  or  profiles.  The  profiles  are  automatically  compared 
with  incoming  data  and,  if  favorable  matches  occur,  notifications  are  auto¬ 
matically  generated,  Notifications  contain  only  that  information  necessary 
to  provide  a  user  with  the  essential  elements  of  the  data  input  to  storage. 
If  a  user  is  interested  in  obtaining  more  information  than  is  provided  by  a 
notification,  the  retrieval  function  of  the  system  is  used  to  obtain  the  new 
data. 

A  current  awareness  capability  was  developed  for  PSES  to  illustrate  the 
overall  concept  as  visualized  within  the  framework  of  an  operational  data 
handling  system.  The  current  awareness  techniques  thus  developed  consist 
of  two  computer  programs.  One  program  is  responsible  rvr  building  profiles. 
The  other  performs  the  matching  operation  between  thest  profiles  and  data 
to  be  entered  into  the  data  pool  and  generates  notifications  as  appropriate. 
Both  of  these  programs  operate  within  the  time-shared  evnironment  of  the 
AN/FSQ-32  computer. 


PROFILE  BUILDING 


Development  of  user  profiles  is  accomplished  by  program  BUILD  (see  Appendix  X). 
BUILD  accepts,  as  input,  data  values  associated  with  select  data  categories. 
These  values  indicate  the  areas  in  which  a  user  is  interested.  Interest  can  be 
expressed  at  broad  or  narrow  levels,  depending  upon  the  values  supplied  for  the 
various  elements. 

Because  the  matching  process  compares  profiles  with  data  being  entered  into 
the  data  pool,  categories  used  to  express  profiles  are  identical  to  the  ele¬ 
ments  used  to  define  an  entry  within  the  data  pool  as  described  in  Appendix  X. 
The  categories  used  for  profile  development  are: 

SYSTEM  (Indicated  data  base  to  be  used) 

MISSION  PHASE 
MISSION  SEGMENT 
FUNCTION 

PERSONNEL  TYPE  (AFSC  and  NASA  personnel  designators) 
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Profiles  are  developed  in  a  conversational  mode  from  a  remote  console.  BUILD 
provides  options  to  the  user  and  the  user  supplies  appropriate  responses  along 
with  the  actual  data  values  that  are  to  be  used  for  comparison  during  the 
watching  process.  It  is  not  necessary  to  use  all  categories  when  developing 
a  profile,  but  all  data  values  supplied  for  MISSION  PHASE,  MISSION  SEGMENT,' 
and  FUNCTION  must  exist  in  the  corresponding  elements  of  entries  being  entered 
into  storage  before  notifications  will  be  generated.  For  the  categories 
PERSONNEL  TYPE  and  HARDWARE  INFORMATION,  BUILD  accepts  multiple  values,  any 
one  of  which  may  match  and  cause  a  notification,  provided  that  favorable 
matches  occur  in  the  other  categories  as  well.  Thus,  as  in  the  first  profile 
in  figure  10,  both  hardware  Items,  "throttles"  and  rudder",  are  listed  as 
being  of  interest.  Any  entry  in  which  either  or  both  of  these  items  of  hard¬ 
ware  are  used  is  considered  acceptable,  if  all  other  qualifications  for  the 
other  categories  are  favorable.  The  output  of  BUILD  is  a  sepa. isle  of 
information  for  each  profile,  each  identified  by  a  user-assigned  name. 

Figure  10  illustrates  a  typical  run  of  program  BUILD  as  controlled  at  an  on¬ 
line  teletype  terminal. 


PROFILE  MATCHING 


Profile  matching  is  accomplished  by  program  MATCH.  The  program  is  operated 
from  an  on-line  console  and  accepts  as  input  the  names  of  the  profiles  that 
are  to  be  processed.  The  profiles  are  located  in  storage  and  compared,  in 
turn,  with  a  predefined  block  of  task  data  slated  for  entry  into  the  data 
pool.  Matching  consists  of  comparing  values  specified  in  the  profiles  by 
category  with  values  contained  in  the  same  elements  for  each  entry  of  the 
block  of  input  data.  For  each  entry  that  meets  the  specifications  of  the 
user's  profile,  a  notification  is  generated  on-line. 

Notifications  include  the  following  information: 

•  The  system  with  which  a  qualifying  task  is  associated 

•  The  name  of  the  task 

•  An  entry  number  for  the  task  (Each  entry  is  manually  assigned  a  unique 
number  as  it  is  prepared  for  entry  into  the  data  pool.  The  number  can 

be  used  as  an  identifier  to  obtain  more  information  regarding  the  entry  bv 
use  of  the  normal  retrieval  function  of  the  PSES.) 

•  The  type  of  entry  (new  or  modified)  ("New"  implies  that  the  task  is  being 
entered  Into  the  data  pool  for  the  first  time.  "Modified"  implies  that 
the  task  already  exists  in  the  data  pool  and  is  being  replaced  as  a  result 
of  a  modification.  Information  about  the  nature  of  the  modification  is 
briefly  outlined  in  the  notification.) 

Figure  11  illustrates  a  typical  run  of  the  program  as  controlled  at  an  on-line 
teletype  terminal.  Three  notifications  are  shown. 
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ENTER  PROFILE  NAME 
PRQFL1 

LIMIT  SYSTEM? 

YES 

ENTER  SYSTEM 
C-5A 

LIMIT  MISSION? 

YES 

ENTER  PHASE 
PREFLIGHT  OPERATIONS 

ENTER  SEGMENT 
TAXI 

LIMIT  FUNCTION? 

NO 

LIMIT  HARDWARE? 

YES 

NAME  #l=TKROTTLES 
NAME  #2=RUDDER 
NAME  #?=END 

LIMIT  FERSONNEL? 

YES 

CODE  #>10552 
CODE  #2-m 

PROFILE  COMPLETED. 
ANOTHER  PROFILE? 

YES 

(a) 


ENTER  PROFILE  NAME 
PSOFL2 

LIMIT  SYSTEM? 

YES 

ENTER  SYSTEM 
C-5A 

LIMIT  MISSION? 

YES 

ENTER  PHASE 
FLIGHT  OPERATIONS 

ENTER  SEGMENT 
NONE 

LIMIT  FUNCTION? 

NO 

LIMIT  HARDWARE? 

NO 

LIMIT  PERSONNEL? 
YES 

CODE  #1=60570 
CODE  #c-END 

PROFILE  COMPLETED . 
ANOTHER  PROFILE? 

NO 


(b) 


(Underlined  words  are  sample  user  entries;  all  others  are  program  generated) 


Figure  10.  On-Line  Development  Of  User  Profiles 
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ENTER  PROFILE  NAME 
PR0FL1 

STANDBY 
NO  MATCH 

E3T”R  PROFILE  NAME 
PR0FL2 

STANDBY 

1)  SYSTEM  -  C-5A;  TASK  -  SET  ALTIMETERS 
ENTRY  #  200;  TYPE  ~  NEW  ENTRY 

2)  SYSTEM  -  C-5A;  TASK  -  PERFORM  10,000'  CHECK 

ENTRY  §  205;  TYPE  -  MODIFIED  ENTRY  -  LOADMASTER  INCLUDED  IN  TASK 

3)  SYSTEM  -  C-5A;  TASK  -  COMPLETE  CRUISE  CHECKLIST 
ENTRY  #  218;  TYPE  -  NEW  ENTRY 

MATCH  CONCLUDED 


(Underlined  words  are  sample  user  entries;  all  others  are  program  generated) 


Figure  11.  On-Line  Generation  Of  User  Notifications 
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COMMENDATIONS 


Certain  steps  remain  to  be  taken  to  provide  a  more  useful  current  awareness 
capability. 

Investigation  should  be  conducted  to  determine  the  categories  of  data  the 
majority  of  users  wish  to  use  in  specifying  data  of  interest.  The  Inves¬ 
tigation  could  be  conducted  either  by  questionnaire  or  personal  interviews 
with  potential  system  urors.  The  profile-building  program  can  then  be  fur¬ 
ther  developed  to  ref If  :t  t.ese  user-interest  areas. 

The  profile-matching  program  should  be  modif  ed,  allowing  the  user  to  specify 
either  "o-line  or  off-line  modifications. 

Procedures  governing  the  operation  of  the  current  awareness  function  should  be 
integrated  with  those  for  ^.ie  periodic  updating  of  the  data  pool.  Since  the 
current  iwarenes :  function  operates  on  data  to  be  entered  into  the  data  pool, 
its  operation  sNu’J  takf  plac^  in  the  same  time  period  the  updating  is  per-, 
formed. 
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SECTION  V 


VOCABULARY  STANDARDIZATION  AND  THESAURUS  DEVELOPMENT 


INTRODUCTION 

The  establishment  of  methods  and  techniques  for  controlling  vocabulary  is  a 
necessary  function  of  any  computer-based  retrieval  system.  The  standard¬ 
ization  of  vocabulary  is  but  one  part  of  the  overall  research  that  is  based 
on  th  assumption  that  a  user-oriented  computerized  data  handling  system 
will  nelp  draw  human  factors  specialists  and  others  involved  in  system 
development  programs  closer  to  needed  data. 

Human  factors  task  data  generated  in  support  of  the  ALCC,  C-5A,  and  Saturn 
programs  were  used  to  generate  the  experimental  data  pool.  To  keep  tern 
proliferation  to  a  minimum  while  establishing  the  data  base  content,  a  means 
was  sought  to  maintain  adequate  control  over  the  vocabulary.  One  of  the 
most  used  tools  for  vocabulary  control  is  the  thesaurus.  It  is  designed 
oecifically  to  alleviate  term  proliferation  through  synonym  control.  The 
thesaurus  allows  the  data  user  to  assign  terms  freely,  but  establishes 
acceptable  terms  to  facilitate  retrieval.  These  terms  are  used  as  descrip¬ 
tor*  when  retrieving  data  from  computer  storage.  (An  acceptable  term  is 
'ne  at  is  assigned  as  precise  a  definition  as  the  character  of  the  word 
permit  An  authorized  synonym  is  a  term  having  a  meaning  identical  to  or 
very  si  ilar  to  a  particular  acceptable  term.)  Care  must  be  taken  to  select 
synonyms  that  are  synonymous  with  only  one  acceptable  term. 

Two  relatt  1  functions  of  a  controlled  vocabulary  are  to  avoid  indexing  iden¬ 
tical  terms  of  information  under  different  descriptors  and  to  assure  that 
all  information  retrieved  under  a  given  description  is  related.  When  these 
functions  ire  rot  fulfilled,  available  data  are  denied  the  user  and  unwanted 
nformatior  is  retrieved.  The  more  related  the  meanings  between  descriptors, 
t  e  greater,  the  care  that  must  be  taken  to  assure  that  the  data  are  properly 
indr  ed. 


THFS A,  IDS  DEVEI  OPMENT 

A  detailed  discussion  of  the  methodology  and  developmental  process  that  led 
to  the  ‘velopmerr  of  a  human  factors  thesaurus  was  reported  in  Oiler  (1968). 
In  itj  present  form,  the  thesaurus  consists  of  a  glossary  of  verbs  and  nouns, 
rules  governing  the  use  of  grammatical  categories,  and  indexes  designed  to 
assist  the  user  in  making  an  appropriate  choice  of  terms.  For  any  classifi¬ 
cation  scheme  to  function  successfully,  all  qualifying  terms  must  De  clearly 
defined  ir.  1  all  terms  must  be  mutually  exclusive.  Without  this  clarity,  the 
indexers  will  be  confused  about  where  to  file  an  item  of  information  or  a 
related  sei  es  of  information.  A  controlled  vocabulary  is  imperative  for 
task  data  bases  because  tney  cover  a  wide  range  of  subject  matter  and  po¬ 
tential  users  have  diverse  backgrounds  and  different  information  requi rements . 
Ine  controlled  vocabulary  must  be  general  but  at  the  same  time  provide  the 
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capability  of  expressing  a  wide  range  of  concepts.  Basically,  the  controlled 
vocabulary  provides  the  user  with  predetermined  series  of  defined  terms  to 
describe  the  Items  fn  the  data  base.  By  providing  the  user  with  standardized 
terms  for  which  the  meaning  Is  clearly  understood,  loose  and  inconsistent  use 
of  terns  can  be  eliminated.  The  controlled  vocabulary  reduces  the  problem 
caused  by  synonyms  and  multiple  meanings  for  a  single  term  by  assigning  only 
one  acceptable  tarm  for  each  concept.  A  cross-reference  index  of  acceptable 
terms  Is  provided  to  aid  the  user  in  selecting  proper  terms  if  assistance  i- 
required  when  requesting  data.  A  glossary,  containing  all  descriptors,  i< 
Included  as  part  of  the  controlled  vocabulary.  The  definitions  of  all  de¬ 
scriptors  are  controlled  by  the  glossary.  Both  the  cross-reference  index  and 
the  glossary  are  arranged  alphabetically  and  are  separated  into  grammatical 
categories.  Cross-reference  indexes  of  acceptable  tenns  and  their  synonyms 
are  Included  in  the  thesaurus  to  assist  the  users  in  selecting  a  proper  de¬ 
scriptor  when  there  is  uncertainty  regarding  the  acceptability  of  a  term  under 
consideration.  Accompanying  the  controlled  vocabulary  is  a  set  of  rules  that 
govern  usage  of  various  grammatical  categories  and  punctuation.  Tb-'1  vocabu¬ 
lary  and  rules  for  usage  have  applicability  beyond  t.‘,  •-  experimental  data  pool 
and  should,  with  minor  modifications,  be  applicable  to  most  dat«  pools  con¬ 
taining  aerospace  system  human  factors  task  data. 

The  individual  components  of  the  thesaurus  are  examined  and  the  developmental 
work  Is  described  in  the  paragraphs  that  follow.  Computer  assisted  capabili¬ 
ties  for  tnesaurus  control  are  also  discussed  in  terms  of  constraints  of  the 
Time-Shared  Data  Management  System  (see  Sect.^.n  III). 

Action  Verbs 

To  develop  a  controlled  vocabulary  capable  of  adequately  expressing  task  stare 
ments  In  a  precise,  distinct,  and  unamoiguous  manner,  it  was  necessary  to  aD- 
ply  effective  control  measures  on  action  verbs.  Action  verbs  express  a  par¬ 
ticular  form  of  action,  e.g.,  "operate",  "monitor",  and  "rotate'  ,  as  opposed 
to  verbs  that,  express  only  states  of  being  and  the  grammatical  conditions  of 
number,  person,  and  tense,  e.g.,  "is" ,  "am’’,  "are",  was",  and  were".  It  ir 
iterative  to  control  action  verbs  since  they  express  the  action  in  task 
statements.  The  lack  of  standardization  bewween  systems  and  inconsistencies 
within  systems  in  the  use  of  action  verbs  was  found  to  be  so  extreme  that  it 
was  frequently  necessary  to  rely  on  the  context  in  wl.ich  verbs  appeared  fn 
clarify  their  meaiing.  Often,  human  actions  v  re  exoressed  by  verbals  (forms 
of  verbs  that  function  as  nouns  or  adjectives)  rather  than  by  ver^s  lack 
of  standardization  presents  difficulties  in  the  extraction  of  data  for  non- 
autoflwted  systems,  but  are  intolerable  in  a  co nputerized  fact  retrieval  sys¬ 
tem  where  the  need  to  qualify  on  individual  descriptors  is  a  basic  requirement 

Listed  below  are  the  sequential  steps  taken  in  the  development  of  a  controlled 
vocabulary  of  action  verbs: 

(1)  The  initial  step  was  to  extract  all  action  verbs  (inci.  iinq  verbals'1  that 

app  ired  In  the  data  for  ALCC  and  to  record  the  frequency  of  occurrence 

of  each. 


(2)  Based  on  the  frequency  of  usage,  a  tentative  judgement  was  •rode  of  whicn 


verbs  were  synonyiwus . 

(3)  To  seep  the  verb  list  within  manageaDle  limits,  certain  types  of  action 
verbs  were  excluded.  Those  exclusions  did  not  limit  the  types  of  actions 
that  can  be  expressed.  Specialized  verbs  were  eliminated  because  the 
same  concept  can  be  expressed  adequately  and  succinctly  by  a  generalized 
verb  plus  the  noun  form  of  the  specialized  verb.  For  example,  "chock 
(specialized  verb)  wheels',  can  be  expressed  by  "place  (generalized  verb) 
chock  in  front  of  wheels".  No  verbs  with  the  prefix  "un"  were  allowed, 
e.g.,  "unscrew".  The  same  concept  can  be  expressed  by  phrases  such  as, 
"remove  screw".  Compound  verbs  formed  from  a  noun  or  adjective  were  also 
excluded.  This  type  of  verb  is  generally  hyphenated,  e.g.,  quick-freeze 
or  force-fed. 

(4)  A  tentative  selection  of  acceptable  action  verbs  was  made  on  tne  basis 
of  the  highest  frequency  of  occurrence. 

(5)  A  tentative  sesection  was  made  of  terms  that  were  at  least  partial  syn¬ 
onyms  to  one  or  more  of  the  previously  selected  acceptable  terms.  These 
were  retained  in  the  synonym  list,  tne  others  w^e  discarded. 

(6)  Acceptable  action  verbs  were  carefully  defined  to  reflect  their  most 
prevalent  usage  in  task  statements. 

(7)  A  decision  was  made  to  express  alt  action  verbs  in  the  present  tense, 
indicative  mood.  The  present  tense  was  chosen  because  it  is  used  to 
make  statements  that  ere  generally  true,  without  reference  to  time.  The 
indicative  mood  was  chosen  because  this  is  the  usual  form  of  an  action 
verb  in  jentences  or  clauses  that  present  facts  or  make  statements. 
(Subsequent  evaluation  proved  that  all  actions  occurring  in  the  task 
statements  could  be  satisfactorily  expressed  in  this  manner.) 

(8)  The  definitions  of  the  acceptable  verbs  were  examined  (item  6.  above) 
to  insure  that  no  acceptable  verb  was  a  synonym  of  another.  This  pro¬ 
cess  was  conducted  to  eliminate  possible  oversights  that  could  rer,<lt 
in  acceptable  verb  redundancies . 

(9)  Additional  synonyms  that  were  nut  in  the  task  statements,  but  which  are 
in  common  use,  were  added.  These  terms  were  obtained  from  specialized 
glossaries  of  terms  and  from  standard  dictiona-ies . 

(10)  After  the  acceptable  action  verb:  and  their  synonyms  were  $t 'ndar-M zed 
for  ALCC  data,  the  list  «as  applied  to  C-5A  data.  Necessary  additions 
and  modifications  were  made  to  satisfactorily  express  a  wider  ranqe  of 
task  statements.  The  second  system  required  only  an  8  to  101  change 
(mainly  additions)  to  the  orioina!  list.  These  changes  allowed  the  verb: 
to  satisfactorily  express  all  actions  contained  ir  the  task  statements. 
After  the  verb  list  v  as  standardized  for  two  of  the  systems,  it  was 
applied  f-j  the  Saturn  data.  A  change  of  less  than  1*  was  required  to 
adequately  express  all  action  contained  in  the  Saturn  task  statements. 
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par,.  the  scope  of  acceptable  verbs  to  accommodate  other  aerospace  system  data. 
For  example,  since  none  of  the  three  systems  used  were  weapon  systems ,  action 
verbs,  such  a  "Fire",  "range",  and  "track''  would  need  to  be  added. 

A  cross-reference  index  of  action  verbs  and  their  authorized  synonyms  was 
developed  to  assist  the  user  in  quickly  determining  whether  an  action  verb 
und‘  r  consideration  is  an  acceptable  term  or  an  authorized  synonym.  Once  an 
acceptable  term  is  selected,  reference  must  be  made  to  the  glossary  for  the 
precise  meaning  of  the  term.  If  the  select?  term  does  not  provide  the  mean¬ 
ing  desired,  the  user  may  refer  back  to  the  index  or  examine  the  glossary 
directly  to  locate  an  appropriate  term.  The  cross-reference  index  of  verbs 
(accepted  and  synonyms)  is  arranged  alphabetically.  Acceptable  verbs  were 
designated  by  the  letters  "AT"  and  synonyms  by  the  letter  "S".  Acceptable  terms 
having  synonyms  were  listed  opposite  the  synonym.  This  form  provides  quick 
reference  to  acceptable  terms,  as  illustrated: 

Finish  ($)----- . . . Complete  (AT) 

Fly  (AT) 

Follow  (AT) 

curnish  (S) - - - - - Provide  (AT) 

A  second  index  contains  all  acceptable  action  verbs  having  synonyms.  The  list 
was  arranged  alphabetically  by  acceptable  verbs  with  the  synonyms  listed  di¬ 
rectly  below  the  acceptable  verbs,  as: 


Check  AT 

Acknowledge  S 

Confirm  S 

Veri fy  S 

Close  AT 

Seal  S 

Shut  S 


This  list,  provides  a  quick  reference  to  acceptable  verbs  having  synonyms. 

Nouns 

The  ricuns  in  the  glossary  were  drawn  from  task  statements  by  the  same  method 
used  to  cumpile  tne  initial  list  of  action  verbs.  Since  the  nouns  were 
drawn  from  task  statements,  they  were  net  restricted  to  hardware  identifiers. 
They  encompass  a  wide  range  of  persons,  places,  things,  qualities,  a«.  * '  n , 
and  ideas.  To  give  the  list  greater  applicability  over  a  wider  range  r 
aerospace  systems,  system-specific  terms  were  excluded,  A  glossary  of  system- 
specific  nouns  was  recommended  to  insure  the  understanding  of  such  terms. 

There  were  two  primary  reasons  for  compiling  glossaries  of  acceptable  nouns: 
(1)  to  provide  the  user  with  a  convenient  source  for  determining  the  meanings 
of  nouns  ne  is  uncertain  of,  and  (?)  to  assist  the  indexer  in  selecting  the 
proper  term  for  indexing  an  item  of  data.  It  also  acts  as  a  control  device 
against  the  proliferation  of  synonyms. 
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-if  d  -,f  pr  noun-;  ,  sue1'  as  *rjyp  names .  No  attempt  was  made  to  comp1  >e  a 
list  f  ' ynonyms  for  nouns.  Although  such  a  list,  would  be  useful  in  reducing 
the  r,  1  iteration  of  term:,  the  specific  nature  of  most  of  the  nouns  preclude 
the  use  of  or  scverlv  limit  the  number  of  synonyms.  Nouns,  like  "aircraft", 
having  a  number  of  synonyms,  e.  g.,  "airplane",  "aeroplane" .  and  "plane",  are 
the  exceptions  rather  than  the  rule.  In  contrast  to  the  generalized  meaning 
of  action  verbs,  the  meanings  of  most  nouns  are  specific  to  aerospace  systems. 

Abbreviations 

A  list  of  abbreviations  was  compiled  by  extracting  all  of  the  abbreviations, 
including  acronyms,  occurring  in  the  three  systems  composing  the  experimental 
data  pool.  Many  cf  the  abbreviations  contained  in  the  list  are  not  in  stan¬ 
dardized  lists  of  abbreviations,  since  they  often  represent  a  convenient 
shorthand  used  by  data  generators.  Care  was  exercised  in  assigning  meaning 
to  abbreviations  because  many  had  multiple  meanings.  The  list  nrovides  the 
user  with  a  reference  to  the  acceptable  meaning  of  the  aobrevu. ..ed  terms. 

Most  of  the  abbreviations  should  be  eliminated  and  replaced  by  the  full  terms. 
Abbreviations  result  in  far  more  confusion  to  the  user  than  can  be  justified 
by  the  shorter  form  of  expression.  The  only  abbreviations  that  might  be  re¬ 
tained  are  those  whose  most  frequent  meanings  are  already  standardized,  e.g., 
"CPS"  for  "cycles  per  second",  or  when  tne  meaning  is  known  to  a  large  seg¬ 
ment  of  the  user  population,  e.g.,  "IFF/SIF"  for  "Identification  Friend  or 
Foe/Selective  Identification  Feature.’ 


Punctuation 


Due  to  the  special  meanings  assigned  to  punctuation  marks  by  the  computer 
programs,  it  is  necessary  to  keep  their  use  to  a  minimum  in  or  surrounding  the 
descriptor.  It  is  necessary  to  enclose  compound  nouns,  such  as  "pulse  am¬ 
plitude  modulation"  or  "rotary  switch"  in  parentheses  (or  similar  techniques) 
so  the  program  will  recognize  them  as  single  descriptors. 

Pronouns 

Pronouns  are  prohibited.  Pronouns  are  words  that  represent  a  person  or  thing 
or  idea  withou*  naming  it.  Normally  the  meaning  of  a  pronoun  is  completed  by 
referring  to  a  noun  (called  an  antecedent)  that  names  the  person,  thing  or 
idea  previously  uspd.  This  form  of  identification  in  a  fart  retrieval  system 
is  uuacv-c,  r  1  ’  v,c  cue  ui  c.c!  ••  \.c  .;i  wii  ic.i  viiw  ~  i  cli  teveo 

cannot  be  predetermined.  Therefore,  the  computer  cannot  know  what  the  ante¬ 
cedent  of  a  pronoun  is. 


Adjectives 

Although  adjectives  were  not  eliminated,  they  were  relegated  to  a  position  of 
little  significance.  Little  need  exists  for  words  that  make  the  mtcnings  of 
nouns  more  precise  because  the  nouns  are  already  precisely  defined.  Also, 
compound  terms  such  as  "qround  support  equipment"  are  considered  as  single 
nouns,  instead  of  two  adjectives  "ground"  and  "support"  modifying  the  noun 
"equipment".  This  convention  was  adopted  so  that  compound  nouns  would  be 
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data. 

.-.d v .  r bs 

Since  the  action  verbs  are  precisely  defined,  there  is  no  need  for  words  that, 
modify  verbs.  Adverbs  may  appear  incidentally  in  the  context  of  retrieved 
data,  but  will  never  be  used  as  qualifiers  for  requesting  data  from  computer 
storage. 


AUTOMATION  OF  THE  HUMAN  rAf.T0R$  THESAURUS 


The  research  work  associated  with  the  development  of  the  human  factors  data 
thesaurus  has  revealed  that  it  is  possible  to  partially  automate  thesaurus 
functions  within  the  constraints  of  TOMS  (see  Section  III).  A  computer 
assisted  capability  for  thesaurus  control  would  provide  the  user  with  useful 
assistance  when  making  requests  by  redu^ng  the  amount  and  frequency  of 
reference  to  the  hard  copy  thesaurus.  The  vocabulary  of  acceptable  terns, 
their  definitions,  authorized  synonyms,  and  rules  for  usage  would  be  in  com- 
pufei  jtorage.  A  discussion  of  the  proposed  system  and  the  rationalization 
for  its  structure  follows. 

®  Acceptable  Verbs 

ATI  verEs~aha"Tffeir  c  ociated  definitions  are  stored  in  the  computer.  Th° 
capability  exists  to  retrieve  only  the  acceptable  verb  or  both  the  accept¬ 
able  verb  and  its  associated  definition.  Depending  on  the  type  of  request, 
one  term  or  the  entire  gl cssary  of  action  verbs  can  be  retrieved. 

*  Au thorized  Synonyms  for  Ac t i on  Verbs 

Tfie  cross-reference  fild  of  "synonyms  and  acceptable  terms  is  organ  ized  so 
that,  depending  on  the  request,  any  one  part  or  all  can  be  retrieved  from 
computer  storage,  when  a  user  is  uncertain  if  a  particular  action  verb 
under  consideration  is  an  acceptable  term,  he  requests  the  answer  from 
the  computer.  If  the  term  under  consideration  is  an  acceptable  term  or 
authorized  synonym,  the  acceptable  term  and  its  definition  are  printed  out. 
The  definition  is  included  so  the  user  can  make  certain  that  the  concept 
is  the  one  he  i  ll  btifUCU  to  express.  This  feature  is  necessary  because, 
in  common  usage,  the  same  word  may  have  several  meanings  and  may  be  a 
synonym  for  several  terms.  If  the  term  under  consideration  is  not  an 
authorized  synonym  for  an  acceptable  term,  the  printout  will  so  indicate. 
The  user  must  then  make  additional  requests  using  words  hc  considers 
synonyms  for  the  original  term  to  locate  the  desired  term.  Or,  he  may 
speed  up  the  process  by  referencing  the  cross-reference  index  of  action 
verbs  for  an  indication  of  an  acceptable  term.  If  both  methods  fail,  the 
user  then  examines  a  copy  of  the  glossary  of  acceptable  verbs  to  locate  the 
appropriate  action  verb. 

*  Rules  Regulating  Action  Verbs 

Yhe  mandatory  and  recommended  rules  governing  the  usaqe  of  action  verbs  are 
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■'  a  •  •  ■  t r  p  !<> ,  i  f  a  subtask  were  being  nip  to  the  computer  ,  and 
rhe  first  word  was  not  ar  acceptable  verb  in  the  or'  vnt  tense ,  was  mis- 
> pel ’  d,  had  an  ’s'  on  the  end,  or  was  a  gerund,  l  °  input  would  he  re¬ 
jects-  and  an  e*  ror  message  generated,  indicating  1  e  first  word  was  not 
an  acceptable  term.  On  the  other  hand,  if  the  first  -d  of  a  subtask 
was  an  acceptable  term,  but  not  an  appropriate  term  for  expressing  the 
action  described,  the  program  would  be  unable  to  detect  tne  rror  Errors 
of  this  nature  must  be  detected  manual sy.  If  an  additional  acceptable 
action  verb,  authorized  synonym,  or  invalid  synonym  were  to  appear  within 
the  context  of  the  subtask  statement,  it  would  go  undetected  by  the  pro- 
'■cur!  since  it  recognizes  only  the  first  word  in  a  task  or  subtask  state¬ 
ment  to  be  an  action  verb.  The  actions  described  by  verbs  appearing  with¬ 
in  the  context  of  the  statement  are  lost  since  they  cannot  be  selectively 
retrieved.  This  type  of  error  also  requires  manual  detection  for  correc¬ 
tive  action. 

•  Acceptabl e  Nouns 

A  capdbi  1  i ty  must  exist  to  either  retnev*  the  acceptable  nouns  separately, 
or  with  their  associated  definition.  Depending  on  the  type  of  request, 
single  terms,  or  the  entire  glossary  of  acceptable  nouns  must  be  retriev¬ 
able. 

When  a  new  noun  not  having  an  authorized  cvronym  occurs  in  the  data  to  be 
indexed,  it  can  be  added,  with  approval  b,  :he  information  specialist  or 
some  other  responsible  person.  In  order  for  a  ne.  noun  to  be  added  to  the 
glossary  of  acceptable  nouns,  it  must  first  be  adequately  defined. 

•  Cross-Reference  Index  of  Acceptable  Nouns 

The  Index  of  acceptable  nouns  and  their  authorized  synonyms  is  structured 
so  that  any  one  part  or  all  can  be  retrieved.  If  a  user  is  uncertain 
whether  a  given  noun  is  an  acceptable  term,  he  can  query  the  computer  for 
the  answer.  Assuming  the  noun  to  be  either  an  acceptable  noun  or  ar, 
authorized  synonym,  the  acceptable  noun  and  its  definition  are  retrieved. 

The  definition  is  included  so  the  user  can  determine  if  the  noun  expres¬ 
ses  the  desired  concept.  If  the  term  under  consideration  is  neither  an 
acceptable  term  or  authorized  synonym,  the  computer  generates  an  error 
message  or  similar  response.  Ihe  user  may  then  choose  to  make  additional 
requests  using  terms  he  considers  synonyms  tor  f't"  term,  to 

the  proper  acceptable  term.  If  both  of  tnese  approaches  fall,  the 
user  must  examine  the  glossary  of  nouns  to  locate  the  desired  term. 

•  Rules  Regulating  Acceptable  Nouns 

Trie  rules  govern  frig  trie  usage  oT  acceptable  ncuns  must  be  organized  so  that, 
depending  on  the  type  of  request,  the  user  can  retrieve  any  one  or  all  of 
the  rules. 

•  Pronouns 

Inasmuch  as  pronouns  are  prohibited,  their  inadvertent  use  will  either  re- 
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‘  >'  ar  error  -»pv.age  nr  ;o  undetected  by  the  computer  programs.  For 
e*amrie,  an  e'-ror  message  is  generated  if  a  user  inputs  the  pronoun  "he" 
whe*'  requesting  data  or  a  task  performed  by  the  pilot.  The  error  message 
indicates  that  tins  term  is  not  a  valid  descriptor,  because  i  :  is  neither 
an  acceptable  noun  or  an  authorized  synonym. 

*  Adjectives 

Presently,  there  is  no  need  for  automated  assistance  ir  handing  adjectives, 
since  they  are  not  used  as  qualifiers  during  retrieval  This  condition  may 
change  with  the  application  of  faceted  classification.  I**  this  classifi¬ 
cation  scheme,  attributes  are  one  . '  the  facets  or  fundamental  points  of 
classification  (see  Section  VI).  Adjectives  such  as  "simultaneous"  and 
“synthetic"  may  be  used  to  express  corrmon  attributes.  If  automated  as¬ 
sistance  for  handling  adjectives  becomes  necessary,  it  should  take  the 
same  form  used  for  action  verbs  and  nouns. 

•  Adverbs 

T Ts  no  need  for  either  glossary  or  rules  govs,  tuna  adverbs  since  they 
are  net  recognized  by  the  programs.  If  an  adverb  is  inadvertently  used  as 
a  qualifier,  an  error  message-  is  generated  indicating  that  the  term  is  an 
invalid  synonym. 

*  Abbreviations 

The  acceptaFTe  abbreviations  and  their  meanings  must  be  organized  so  that 
any  one  or  all  can  be  retrieved. 

*  Rules  Regulating  Abbreviations 

WherT  an  u 1 1 a  u  t ! 1 o rTze cT abbreviation  is  used,  the  printout  must  indicate  that 
the  abbreviation  is  invalid.  he  user  must,  then  apply  the  ur.abbrevi  ated 
term  because  no  synonyms  for  abbreviations  exist.  Tn  all  instanu-s,  the 
full  term  can  be  used,  even  when  an  authorized  abbreviation  exists. 

•  Nomenclature  Codes 

?T  capabiTi ty  muct~exist  to  retrieve  any  one  or  all  nomenclature  codes  from 
the  computer  storage,  depending  on  the  type  of  request  made.  This  allows 
the  user  to  request  hardware  data  by  name  or  by  any  appropriate  designator, 
such  as  a  federal  stock  nu  her,  AN  designator  for  electronic  equipment, 
or  Department,  of  Defense  uniform  designation  for  missiles,  rockets,  anh 
aircraft.  It  is  also  possihi*  tn  rpnuect  fhe  appropriate  designators  for 
given  units  of  equipment.  If  c  user  requests  data  on  a  unit  of  equipment 
cy  a  hardware  code  and  receives  a  reply  that  no  such  number  exists,  he 
then  quests  the  data  by  the  equipment  name. 

•  Pt j  1  pc  Penn  1  a  H  nn  Du*-  Zt'J  ?  Ch. 

The  organi z at! on  o f  the  f 1 1  e  must,  be  such  that  any  one  nr  all  of  the  rules 
can  be  retrieved,  depending  upon  fhn  type  of  request  made.  Mistakes  in 
punctuation  can  result  in  serious  errors,  but  these  are  usually  determined 
manually.  It  is  necessary  to  enclose  compound  nouns  'n  parentheses  (or 
similar  technique)  so  the  computer  can  recognize  them  as  single  descriptors. 
Failure  to  use  parentheses  can  result  in  errors  and  still  be  legal,  for 
examole,  when  data  on  "Doppler  radar"  is  •'equested  and  the  term  is  not 
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enclosed  in  parentheses,  data  on  all  tvpes  of  radars  are  recovered  because 
radar  is  a  valid  descriptor  u»  itself,  "Doppler”  is  not.  If  terms, 

such  as  "estimated  time  of  arrival  '  are  not  enclosed  in  parentheses,  the 
request  is  rejected  and  an  error  message  generated  indicating  an  invalid 
term.  This  is  because  none  nf  tha  f r.-.r  words  in  the  compound  term  are 
tnemselves  valid  descriptors.  Manual  quality  control  must  be  exercised 
when  loading  the  data  base,  because  the  failure  to  enclose  a  compound 
term  lik°  "Doppler  radar"  in  parentheses  results  in  the  partial  loss  of 
the  data. 


SUMMARY 

The  activities  that  led  to  the  development  of  vocabulary  controls  for  the  pSES 

and  associated  research  are  summarized  below: 

•  Glossary  of  precisely  defined  action  verbs--This  glossary  contains  approx- 
TmatiTyl30  generalized  action  ve'lis ,  which  express  human  actions  in 
aerospace  systems.  Most  of  these  terms  are  sufficiently  general  in  nature 
that  they  can  be  applied  to  task  statements  regardless  of  the  type  of 
system. 

•  Glossary  of  non-system  specific  nouns- -Th" s  glossary  contains  approximately 
300  nouns  used  as  descriptors ~7br~tKe  three  aerospace  systems  that  compose 
the  experimental  data  nod  for  the  PSES.  The  glossary,  because  of  its 
non-system  specific  nature,  is  capable  of  fonninq  the  nucleus  for  a  glos¬ 
sary  of  nouns  for  any  aerospace  system. 

•  Rules  regulating  selection  and  use  of  action  verbs--A  detailed  list  of 
mandatory  ancf  recommenJe  ^TTles  was  developed  for  the  selection,  use,  and 
modification  of  artion  verbs.  These  rui°s  are  used  to  minimize  the  in¬ 
consistencies  in  the  meaning  of  action  verbs  and  to  reduce  the  loss  of 
data  in  the  retrieval  process.  They  3lso  allow  action  verbs  to  reflect 
common  meanings,  while  eliminating,  as  far  as  possible,  the  inclusion  of 
jargon. 

•  RiiJjTS  regulati nq  selection  ana  use  of  nouns--These  rules  and  guidelines  are 
not  as_WtaiTecf  or  as  numerous  as  those  for  verbs  because  of  the  greater 
simplicity  in  requlatinq  the  usage  of  nouns. 

•  Rules  pertaining  to  other  grammatical  categories,  punctuation,  nomendature 
a  ncTal)!)  re  v  i  a  tl  o  n  s~Th  e  s  e  rules  are  brief.  Grammar,  punctuation ,  nomen  - 
clature,  and  aWreviatioris  are  simple  to  regulate  and  are  of  less  impor¬ 
tance  than  those  governing  the  use  of  action  verbs  and  nouns. 

•  Review  of  controlled  uo^aN.1 ) *r ie<;  and  ryloc  fgr  usage-~The  controlled 
vocabularies  of  action  verias  and  rules  for  usage  were  reviewed  by  human 
factors  personnel,  grammarians,  lexicographers,  as  well  as  data  generators 
and  potential  users.  Consideration  was  given  to  their  comments. 

•  Modi ti ers--I t  was  determined  that  no  need  existed  at  this  time  for  glos- 


-55- 


s a r i e r.  of  m*  fiers .  "here  ~ a>  be  a  reed  ‘  r  a  -'osoi'-y  of  ao-ec* 
for  a  faceted  classification  scheme  Sec* ion  vl  ,  since  ad-ect 
used  in  the  expression  of  attributes  A  glossary  of  adverbs  is  no 
because  they  are  not  useo  as  descriptors. 


ves  are 
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•  Autonation  of  thesaurus  functions- -The  problem  or  automating  the  controlled 
vocabulary  an"?  ruTes  7o7  usage  was  examined.  It  was  concluded  that  it  is 
possible  to  partially  automate  the  thesaurus  functions. 
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SECTION  V! 

TAjK  data  classification  techniques 

I 

INTRODUCTION  ( 


"'otter  et  ul.  (1966)  reviewed  existing  classification  schemes  having  poten¬ 
tial  usps,  at  least  in  part,  for  classifying  human  factors  task  data.  Alpha¬ 
betical  indexing,  use  of  links  and  roles,  various  forms  of  subject  headings 
and  key  term  inde  es  were  examined,  but  analysis  showed  that  these  methods 
did  not  safisfy  the  reouirements  for  handling  multiple  system  task  data  on  a 
factual  level.  These  classification  systems  were  rejected  for  the  following 
reasons : 

•  They  were  limited  in  scope  and  would  be  ineffective  for  handling  a  wide 
range  of  human  factor0  task  data. 

•  They  were  oriented  towards  single  systems  and  would  be  difficult  fo  adapt 

o r  use  with  multiple  system  data. 

•  'he  techniques  were  document-specific  and  not  readily  adaptable  to  handling 
detai led  factual  data . 

•  They  were  too  complex  or  theoretical  to  oe  used  by  a  computer  system. 

The  data  classification  techniques  developed  for  the  PSES  were  based  or  a 
logical  data  framework ,  hierarchically  arranged.  The  data  elements  (see 
Section  II)  constitute  a  systematic  breakdown  of  the  system  mission,  and  in¬ 
clude  the  personnel -involved  task  descriptions,  task  times,  hardware  .  etc. 

The  user  is  provided  with  a  generalized  capability  to  retrieve  specific  data 
or  class-related  data,  but  canmt  retrieve  functional  relationships  between 
data  items.  Not  only  is  there  s.o  way  in  the  PSES  to  identify  functional  re¬ 
lationships  ,  but.  there  is  no  wav  of  entering  this  type  of  information  into 
the  experimental  data  pool. 

Since  the  classification  scheme  apol led  to  PSES  cannot  be  used  to  identi fy 
functional  rel ationsnips ,  other  types  were  examined,  among  them  faceted 
cl  as  si fi cat  ion 

Faceted  classification  is  a  method  for  expressing  functional  relationships 
existing  between  the  data  items  m  a  task  statement.  It  also  can  provide 
information  on  the  effects  that  giver  charges  to  data  have  on  related  series 
pf  data.  It  provides  Infomat  ion  on  alternatives  that  are  available  to 
rectify  conflicts  arising  <Yor  proposed  changes  to  data.  In  addition  to 
aiding  users  by  providm  :  a  capability  to  handle  functional  relationships ,  it 
also  will  assist  the  information  specialists  'develops  clarification)  and 
the  indexc-  ■  indexes  tems ) .  The  information  s:  ecial  ists  is  assisted  in 
orga,-iz,ng  a  data  base  bv  maximizing  useful  reluticnsnip*  between  tems . 
indexer  is  also  assisted  because  the  indexing  terms  are  grouped  into  clearly 
defined  conceptual  groupings  that  are  arranged  in  generic  hierarchical  order. 
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PRINCIPLES  or  FACETED  CLARIFICATION 

This  discussion  presents  the  general  principles  of  facet  analysis  and  clas¬ 
sification  and  how  it  differs  from  existing  data  classification  systems  that 
handle  human  factors  task  data.  A  working  definition  of  faceted  c’a* sifi  • 
cation  is.  A  faceted  cl  ass i fi cation  system  is  basical ly  one  >•>  whicn  descrip¬ 
tors  *  are  grouped  "By  conceptual  categories  and  ordered  to  shew  their  jper  c 
relation sTiips .  The  system  is  construvtecT sc  that  concepts  are  Tree  to  com¬ 
bine  with  one  another  to  express  more  complex  cor'epls,  This  contrasts  with 
enumerative  systems  in  which  concepts  are  ofte  led  to  other  terms  In 
this  situation  it  may  be  necessary  to  examine  m.iy  classes  to  fine  one  in 
which  the  desired  concept  is  associated  with  the  subject  being  analyzed. 

typically,  classification  systems  start  with  the  most  general  leve1  of  infor¬ 
mation  in  a  given  universe  of  data.  The  information  is  divided  arid  subdi¬ 
vided  until  a  large  classification  tree  is  '''instructed .  (figure  I?  is  an  exam 
pie  of  this  technique  applied  to  simplified  aerospace  system  data  categories.) 
Within  this  framework,  each  data  item  must  be  located  at  a  single  position  in 
the  structure,  This  type  of  russification  leads  to  rigidly  grouped  ca  +  e- 
gories  of  data  in  tne  network.  When  starting  from  the  most  general  level  of 
information,  data  are  divided  into  many  classes  and  subdivision ,  e.g. ,  genus 
and  species.  Each  subject  is  divided  only  one  way,  that  is,  all  subdivisions 
of  a  class  relute  only  to  that  oass.  In  all  lassification  systems  there 
are  logical  divisions,  but  all  divisions  art  not  always  logical.  The  fol¬ 
lowing  example  is  a  series  of  fleets  in  which  a  common  form  of  humar  behav¬ 
ior  can  be  sorted:  ethyl  alcohol  is  a  kind  of  chemical  substance,  1 .quid  is 
a  s ta te  of  the  compound,  potable  is  a  property  of  it,  dying  Is  an  operation 
performed  with  it,  a  glass  is  a  device  Tor  carrying  out  an  operation 
using  it,  man  is  a  consumer  of  the  mixture  and  intoxication  is  a  reaction  from 
it.  The  seven  underlined  words  are  facets  into  which  tne  compound  ai.ohol 
cr  be  sorted.  Rather  than  to  construct  one  large  classification  tree,  facet 
analysis  starts  from  tne  bottom,  it  first  groups  terms  into  categories ,  ar¬ 
ranged  laterally,  since  there  are  no  in ter category  hierarchies .  The  intra- 
category  descriptors  are  organized  into  appropriate  hierarchical  groupings . 

This  classification  technique  can  be  earned  to  the  types  of  data  categories 
in  the  PSES,  Consider  the  following: 

1.  Human  factors  task  statements 

2.  Action  verbs 

3.  Displays 

4.  Controls 


"Descriptors  are  terms  selected  for  inclusion  in  the  thesaurus  'see  $ eerie*  V ; 
for  use  as  indexing  terms  that  describe  the  data  contained  in  the  experimental 
data  pool . 
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5.  Communication 

6.  Group  activity 

1,  Training 

8.  Personnel 

These  terms  cannot  be  regarded  as  having  been  derived  from  human  factors  task 
data  by  a  single  characteristic,  since  they  do  not  share  related  qualities. 
Category  2  1-s  an  action  descriptor,  categories  3  and  4  are  man-machine  inter¬ 
faces  ,  categories  FlinH  S'  are"  human  interactions,  category  ?  is  concerned 'with 
aHTvities  directed  to  performance  improvement,  category  8  is  the  personnel 
type  who  performs  the  tasTcTTmT  category  1  is  the  task  description^!  tself . 
STuiough  these  terms  are  not  collateral  members  of  THe  category  of  human  factors, 
they  can  be  sorted  into  groups,  each  of  which  is  differentiated  on  the  basis 
cf  a  single  characteristic,  e.g.,  action  descriptors.  This  type  of  sorting 
is  called  facet  analysis.  Figure  13  illustrates  how  human  factors  task  data 
can  be-  sorted  Tn to  facets  (conceptual  groupings).  The  eight  categories  be¬ 
come  subdivisions  into  which  data  elements  are  sorted.  The  facets  are  ar¬ 
ranged  laterally,  and  all  hierarchical  groupings  are  internal  to  the  facets. 

The  various  categories  that  make  up  a  given  classification  will  reflect  the 
central  area  of  interest.  If,  for  example,  the  data  to  be  classified  involves 
a  new  manned  aircraft,  categories  concerned  with  operational  and  maintenance 
personnel,  task  statements,  equipment,  training  requirements,  operational 
environn,  t,  etc.  should  be  included.  The  list  can  be  expanded  to  cover  all 
of  the  behavioral  aspects  of  each  level  of  interest,  as  well  as  the  activities 
associated  with  manufacture,  assembly,  and  personnel  testing. 

It  will  be  necessary  to  apply  vocabulary  control  techniques  described  in  Sec¬ 
tion  V  to  assure  that  the  terms  chosen  lor  descriptors  comply  with  the  rules 
governing  word  usage.  The  glossary  of  acceptable  action  verbs  and  nouns 
should  Ke  relied  on  when  choosing  descriptors  to  avoid  proliferation  of  syn¬ 
onyms.  Unless  these  conventions  are  followed,  misunderstanding  the  meaning 
of  terms  will  result  among  the  users  and  data  will  be  lost  in  the  retrieval 
process.  The  terms  are  sorted  into  appropriate  facets--!. .mogeneous  groups 
of  terms  representing  the  central  area  of  interest  in  the  data  being  clas¬ 
sify.  By  way  of  ilustration,  the  six  terms  mentioned  earlier  to  cate¬ 
gorize  human  factor  task  data  are  characteristic  of  the  divisions  by  which 
terms  are  derived.  The  characteristics  are  also  logical  categories  in  whi'  t 
to  assemble  terms.  They  express  certain  relations  or  links  between  terms, 
e.g.,  action  descriptors/man-machine  i nterface/ personnel ,  and  action  descrip- 
tors/human  interacts on/performance  improvenient/pe^sonnel . 

In  sunriary,  faceted  analysis  is  similar  to  tradition  1  rules  of  logical 
division,  but  differs  in  two  significant  ways.  First,  the  analysis  performed 
to  construct  the  scheme  is  stricter,  since  every  category  must  be  isolated, 
every  new  characteristic  of  a  division  must  be  stated  precisely,  and  new 
links  must  be  recognized.  Secondly,  the  various  facets  and  categories  are 
not  bound  into  rigid  enumerative  schedules  but.  are  free  to  combine  with  each 
other  so  that  all  of  the  rela''ons  between  them  can  be  expressed.  In  essence, 
by  providing  a  means  for  comb  mg  terms  into  compound  subjects,  faceted 
classification  allows  for  the  more  adequate  expression  of  the  complex! tv  of 
information. 
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PROPOSED  DESIGN  OF  A  FACETED  CLASSIFICATION  SYSTEM 


Faceted  classification  as  described  here  (infers  from  tne  original  faceted 
system  developed  by  Raganthan  (1957  and  1965)  and  modified  by  Vickery  (1966). 

The  later  form  of  Raganthan’s  system  was  called  colon  classification,  but 
this  term  merely  refers  to  the  use  of  colons  to  separate  facets.  Their  con¬ 
cept.  of  dividing  data  into  a  series  of  related  facets  was  incorporated  into 
the  selected  approach,  but  their  detailed  indexing  schedules  and  classifi¬ 
cation  schemes  were  not  utilized.  They  were  developed  for  the  classification 
of  documents  and  do  not  readily  lend  1 ves  to  the  indexing  and  classi¬ 

fication  of  disn°te  items  of  "human  factors  task  data.  In  the  selection  and 
organization  of  facets,  greater  reliance  was  placed  on  the  systems  developed 
by  the  English  Electric  Company  (1961)  and  Mulvihill  and  Brenner  (1966). 

These  two  are  library  classification  systems  and  are  better  applied  for  de¬ 
tailed  indexinq  rather  than  for  book  classification.  Trie  faceted  structure 
of  the  detailea  tables  allows  for  a  fairly  logical  and  concise  arrangement 
of  concepts  in  a  complex  subject  field.  This  concentration  on  in-dept:. 
classification  appears  to  provide  a  better  point  of  departure  for  the  clas¬ 
sification  of  factual  human  factors  task  data  than  one  more  suited  to  docu¬ 
ment  classification.  While  these  systems  are  primarily  concerned  with  equip¬ 
ment,  personnel,  economic  factors,  etc.,  some  of  the  concepts  can  be  utilized 
in  the  construction  of  a  classification  system  to  handle  human  factors  task 
data.  The  proposed  design  incorporates  the  principles  related  to  faceted 
classification  described  earlier.  The  data  are  grouped  into  a  series  of 
laterally  arranged  conceptual  facets  that  represent  the  central  areas  of  in¬ 
terest  for  human  factors  task  data. 

The  initial  step  was  to  develop  a  series  of  facets  for  handling  the  type  of  data 
contained  in  the  experimental  data  pool.  There  is  a  mere  detailed  breakdown 
of  the  data  elements  in  the  faceted  system,  but  the  PSES  element  list  can 
be  expanded  to  any  degree  desired.  The  level  of  detail  is  one  of  degree, 
not  of  kind.  The  faceted  system  can  provide  the  same  type  of  data  retrieval 
capability  as  PSES  and  can  be  implemented  on  the  Time-Shared  Data  Management 
System  (TOMS)  (see  Section  in).  Due  to  the  limitations  of  TDMS  for  hand¬ 
ling  data  that  are  organized  on  multiple  hierarchical  levels,  the  data  must 
be  arranged  into  a  series  of  rather  lengthy  entries.  A  list;  of  these  data 
elements  and  their  definitions  is  presented  in  Appendix  XI  .  Each  entry  in¬ 
cludes  the  pertinent  hierarchical  data  on  system,  phase,  segment,  task,  and 
subtask-related  data  describing  the  action,  personnel,  and  hardware  involved. 

The  faceted  system  described  above  is  limited  to  data  retrieval;  by  itself 
it  provides  no  capability  to  show  the  functional  relationships  that  exist 
between  facets.  Thus,  it  can  relate  one  item  of  data  to  another,  such  as 
action,  personnel,  and  equipment,  but  cannot,  be  used  to  determine  what  ef¬ 
fects  a  change  in  ta^k  sequencing  will  have  on  the  performance  of  the  tasks. 

To  provide  a  means  for  identifying  functional  relationships,  it  will  be 
necessary  to  add  another  order  of  facets.  These  facets  constitute  a  depen¬ 
dent  category  that  contains  information  that  will  modify  or  expand  on  the 
data  In  the  other  facets.  These  facets  are  called  attributes.  Attributes 
are  defined  as  any  property  or  quality  of  an  element  in  the  data  base  that 


-62- 


is  a  meaningful  entity  by  itself.  Attributes  consist  of  information  known 
about  the  da+?  contained  in  me  data  base.  To  facilitate  the  user  in  deter¬ 
mining  what  information  is  available,  each  task  and  subtask  must  contain  in¬ 
dicators  that  inform  the  user  whether  the  attribute  facets  contain  infor¬ 
mation  on  toe  elements  involved  in  that  particular  task  or  subtask.  To 
identify  elements  having  associated  attributes,  it  will  be  necessary  to  query 
the  attribute  facets.  It  will  be  possible  to  ask  if  one  or  more  elements 
have  associated  attributes  or  if  any  elements  have  attributes.  A  minimum 
of  two  requests  will  be  necessary  to  determine  what  the  actual  attributes  are. 
The  first  request  provides  the  names  (or  numbers)  of  the  elements  having 
associated  attributes. 

The  attributes  are  limited  to  those  that  are  direct  quantifiable  modifiers 
to  elements  of  task  data,  :>uch  as  performance  characteristics ,  training  re¬ 
quirements,  reliability,  and  operational  environment.  A  description  of 
reliability  should  suffice  to  illustrate  the  content  and  use  of  an  attribute 
facet.  Information  is  provided  on  the  probable  error  rates  associated  with 
different  time  allowances  for  the  performance  of  specific  tasks  or  subtasks. 

It  also  indicates  whether  error  rates  within  acceptal  a  limits.  With 
this  type  of  information  the  specialist  is  provided  with  probabilities  as¬ 
sociated  with  time  changes  and  the  effect  of  time  changes  on  the  performance 
of  tasks  or  subtasks.  If  a  time  change  results  in  an  unacceptable  error  rate, 
but  the  time  change  was  considered  to  be  mandatory,  then  other  attribute  files 
may  oe  qMeried  for  assistance.  For  example,  ^'formation  in  the  training 
requirements  facet  night  indicate  that  zrror  rates  can  be  reduced  through 
additional  training.  When  a  tentative  solution  to  the  problem  has  been 
reached,  the  economics  factor  facet  can  be  explored  to  determine  whether  the 
additional  training  required  is  economically  feasible. 

Definitions  of  representative  attribute  facets  are  presented  below  to  exem¬ 
plify  their  varied  nature  and  content: 

*  Economic  Factors— Contains  the  cost  of  equipment,  supplies,  facilities, 
traTrmig,  transportation,  and  anything  else  on  which  a  price  tag  can  be 
or  is  placed. 

*  Location— Consists  of  geographic  locations  where  the  system  or  any  of  its 
facilities  might  be  relocated. 

*  Operational  Environment— Contains  a  listing  of  the  conditions  under  which 
a  sys tern 1 s  opera HonaT" support  or  maintenance  operations  may  occur--it 

is  subdivided  into  temperature  ranges,  altitudes,  and  regions,  e.g.,  land, 
sea,  outer  space,  etc.  The  breakdown  can  be  as  detailed  :<s  tne  data  war¬ 
rant. 

*  Reliability  and  Maintai  <nility— Reliability  refers  to  the  probability  that 
a  system  or  any  of  ftFTtuman  or  equipment  components  will  perform  a  re¬ 
quired  function  under  specified  conditions,  without  failure,  for  a  speci¬ 
fied  period  of  time— this  characteristic  applies  to  hardware  and  man. 
Maintainability  refers  to  the  characteristics  (both  quantitative  and  qual¬ 
itative)  of  hardware  design  and  installation,  which  make  it  possible  to 
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meet  operational  objectives  with  a  minimal  expenditure  of  maintenance  ef¬ 
fort  (manpower,  personnel  skill,  test  equipment,  technical  data,  and  malo¬ 
ti.  jnce  support  facilities)  under  operational  environmental  conditions 
in  which  scheduled  and  unscheduled  maintenance  are  performed.  This  facet 
may  be  expanded  to  delude  repairabi  1  i ty  arid  serviceability  data.  Repair- 
ability  refers  to  those  qualitative  factors  that  determine  the  repaira¬ 
bi  lity  of  equipment,  including  time  to  diagnose  and  isolate  malfunctions, 
time  to  repair  malfunctions  and  place  equipment  in  satisfactory  operating 
condition,  manpower  and  skill  levels  required  to  repair  th s  malfunction, 
and  the  time  the  equipment  is  operating  satisfactorily  without  requiring 
corrective  maintenance.  Serviceability  refers  to  that  function  of  equip¬ 
ment  design,  configuration  installation,  and  operation  which  results  in 
minimization  of  maintenance  requirements,  including  the  use  of  special 
tools,  support  equipment,  skills,  and  manpower.  It  enhances  the  ease  of 
performing  maintenance  and  reduces  th*1  expenditure  of  time  and  material. 


SYMBOLIC  EXPRESSION  OF  TASK  DATA 


A  capability  to  express  statements  symb  lically  will  bu  useful  when  describ¬ 
ing  the  functional  relationships  between  the  component  facets  of  task  data. 
Symbolic  expressions  provide  a  method  of  expressing  statements  or  conditions 
by  conventionalized  characters.  The  symbolic  expressions  described  here  take 
the  form  of  pseudo-algebraic  equations,  hut  are,  in  reality,  a  convenient 
shorthand  technique  for  expressing  task  data  and  have  no  direct  relationships 
to  mathematics.  By  their  concise  nature,  symbols  can  be  used  to  show  inter¬ 
relationships  between  components  of  task  data  more  clearly  than  can  be  shown 
in  narrative  form.  The  clear-cut  and  systematic  divisions  of  data  in  the 
faceted  classification  system  facilitate  the  generation  of  symbolic  expres¬ 
sions.  This  methodology  will  provide  the  aralyst  with  the  capability  to 
better  understand  the  relationships  that  exist  between  the  data.  For  example, 
he  may  want  to  know  how  personnel  are  affected  by  increased  periods  of  ac¬ 
tivity,  how  the  operational  environment  affects  the  performance  of  the  crew 
and  the  equipment,  whether  proper  shelf  levels  are  available  to  maintain  its 
equipment  adequately,  or  any  other  simple  or  complex  relationships. 

Task  information  frequently  changes  during  the  course  of  system  development. 
These  changes  can  be  expressed  symbolically.  For  example,  a  series  of  sym¬ 
bolic  statements  can  be  used  to  express  prior,  concurrent,  and  subsequent 
events  that  exist  in  task  sequences.  Other  typical  changes  that  occur  to  a 
mission  time-line,  that  can  be  expressed  symbolically,  are  as  follow: 

•  Addition  of  new  tasks  or  subtasks 

•  Deletions  of  tasks  or  subtasif? 

•  Changes  in  the  time  to  perform  tasks  or  subtasks,  e.g.,  longer,  shorter 
or  different  times  in  the  mission 

•  Addition  or  deletion  of  personnel 
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j  j 
j  .  I 

9  Reassignment  of  existing  tasks  or  subtasks  to  different  personnel  j 

9  Change  iri  the  sequence  in  which  tasks  or  subtasks  are  performed  : 

•  Addition,  deletion  or  changes  to  hardware  components 

•  Change  in  coordination  requirements  for  tasks  performed  by  more  thar,  oie 

person  due  to  some  change  in  task  assignment  of  one  or  more  of  the  per-  I 

sonnel  involved  in  its  accomplishment.  | 

•  A  change  in  the  mission  of  the  system,  e.g.,  a  change  from  a  reconnaissance  f 

mission  to  a  rescue  mission  may  cause  a  major  change  in  the  time-line.  ] 

Analysts  are  most  concerned  with  changes  of  this  nature  early  in  the  de-  f 

sign  cycle,  when  they  are  modeling  and  conducting  contingency  studies.  | 

The  determination  of  conflicts  is  not  simply  a  matter  of  locating  points  in 
the  time-line  of  o  mission  where  an  individual  must  perform  more  than  one  task 
n"  subtask  or  where  an  equipment  component  is  used  by  more  than  one  individual 
during  the  same  or  overlapping  time  intervals.  Rather,  it  is  a  matter  of 
determining  which  of  these  conditions  constitutes  conflict,  since  an  indi¬ 
vidual  may  be  able  to  perform  several  tasks  or  subtasks  simultaneously.  The 
problem  is  to  determine  which  ones,  if  any,  are  of  a  contradictory  nature. 

For  example,  a  pilot  may  be  required  to  monitor  a  number  of  visual  indicators 
continually  while  steering  an  aircraft  and  may  be  required  to  communicate  with 
a  ground  station  at  the  same  time.  The  simultaneous  performance  of  these 
tasks  may  be  within  the  capabilities  or  the  pilot.  But  a  single  task  may 
result  in  a  severe  conflict  if  it  requires  two  individuals  to  perform  mutually 
contradictory  operations  on  the  same  unit  of  equipment.  Also,  a  task  or  a 
combination  of  tasks  requiring  the  same  individual  to  be  at  two  locations  at 
the  same  time  will  obviously  result  in  a  conflict.  Thn  symbolic  method  of 
expressing  data  may  assist  the  analyst  to  isolate  the  locus  of  contradictory 
operations  and  in  finding  means  of  resolving  conflicts. 

The  terms  and  structure  of  task  statements  and  a  series  of  typical  modifi¬ 
cations  to  the  system  and  mission  profile  are  presented  symbolically  to  il¬ 
lustrate  the  ange  ot  conditions  that  can  be  expressed.  Because  of  its  sim¬ 
plicity,  a  series  of  changes  to  a  mission  time-line  was  chosen  to  illustrate 
the  symbology  and  structure  of  the  statements.  A  typical  task  statement  ex¬ 
pressed  in  symbols  is  show"  below: 

C-5A  -  F0C  [PCN  -  CT3  (T15  -  25)] 

The  f’*"ct  group  of  capital  letters  and  combination  of  capital  letters  and  num¬ 
bers  appearing  in  front,  of  the  orackets  and  separated  from  the  other  letters 
by  a  hyphen  represent  the  system.  The  capital  letters  appearing  directly  after 
the  hyphen  indicate  3  particular  mission  phase  of  the  system,  and  the  lower 
case  subscript  ietter(s)  indicates  a  specific  segment  of  the  mission  phase, 
in  this  example,  C-5A  =  the  system,  TO  =  the  flight  operations  mission  phase, 
and  c  --  the  cruise  segment  of  flight  operations. 

The  positions  involved  'in  the  task  are  expressed  by  capital  letters.  If  more 
than  one  position  ha>  Hie  tame  title,  a  part’r'jla*-  c>  is  distinguished  by  a 
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subscript  number.  These  letters  are  th  first  insertions  inside  the  rackets. 

In  this  example,  P  -  Pilot,  C  =  Copilot,  and  N  =  Navigator. 

IT  *  Independent  Task.  An  Independent  task  is  one  that  involves  only  a  sin¬ 
gle  position  in  its  performance.  When  a  subscript  number  is  added,  .g.,  IT^ 

it  indicates  the  sequential  occurrence  of  the  task  for  a  given  position  since 
the  start  of  a  specified  segment  of  the  mission  phase.  Each  independent  task 
has  the  designators  of  the  appropriate  position  in  front  of  it,  separated  by 
a  hyphen,  e.g. ,  C-IT^ . 

CT  *  Coordinated  Task.  Coordinated  tasks  are  these  that  involve  more  than  one 
j-osition  in  their  performance.  When  a  subscript  number  is  added,  e.g.,  CTg, 

it  indicates  the  sequential  occurrence  of  the  task  since  the  start  of  a  spec¬ 
ified  segment  of  the  mission  phase.  Each  coordinated  task  has  the  desi  tor 
of  the  performing  position  in  front  of  it,  separated  by  a  hyphen.  The  po¬ 
sitions  that  are  active  participants  in  the  task  haye  a  dash  under  their  des¬ 
ignators,  e.g.,  PCN-CT3.  If,  in  this  example,  the  pilot  and  navigator  are 

communicating  with  a  ground  control  station  and  the  copilot  listens  to  the  com¬ 
munication,  the  pilot'and  navigator  are  actively  involved  in  the  task,  whereas 
the  copilot  is  passively  involved. 

T  =  Time.  T  alone  indicates  that  the  time  involved  is  unknown.  Any  numerical 
time  is  expressed  iri  minutes  and  hundredths  of  minutes.  When  T  is  followed  by 
two  sets  of  numbers  separated  by  a  hyphen,  it  represents  the  time  interval  in 
which  a  task  is  to  take  place,  calculated  from  the  start  of  the  mission,  e.g., 

T  15-25.  Time  followed  by  a  single  set  of  numbers  indicates  the  total  time 
allowed  for  the  performance  of  the  task  and  does  not  place  the  task  in  a  se¬ 
quence,  e.g.,  T5.  Time  may  also  be  expressed  as  ‘'continuous"  TC  or  as  re¬ 
quired"  TAR.  Specified  times  are  always  enclosed  in  parentheses,  e.g., 

([  15-25)  or  (T5) ,  whereas  all  other  times  are  r  .  Brackets  [  ]  are  used  to 
enclose  the  tasks  ar.d  their  associated  times,  e.g.,  [PCN  -  CT3  (T  15-25)]. 

44, 

A  superscript  number  ever  T  of  either  IT  or  u,,  e.g.,  IT  ,  CT  ,  in  cates 
an  individual  subtask  performance,  rather  than  the  entire  task.  In  these  cases 
the  time  is  understood  to  be  subtask,  time  rather  than  the  task  time. 

The  following  illustrates  how  the  symbolic  techninue  can  be  utilized  for 
describing  and  revolving  problems  associated  wi  in  the  addition  of  a  new  sub¬ 
task  to  a  mission  time-line.  If  a  time  change  was  necessary  to  CT3>  in  the 

original  example,  it  would  be  necessary  to  identify  the  suotasks  occurring 
prior  to  and  after  the  subtask  being  changed.  It  would  also  be  necessary  to 
determine  if  any  other  tasks  are  being  performed  during  this  time  interval  in 
oHer  to  be  able  to  evaluate  the  effects  of  the  change.  For  example,  if  a 

new  subtask  is  added  between  CT3  and  CTlj,  it  would  be  necessary  to  know  which 

of  the  positions  performed  these  tasks  end  what  time  intervals  were  involved. 

If  the  positions  ind  times  involved  are  P.-CT3  (T  17-18)  and  N-CT*3  (118-19;, 


-66- 


then  the  question  is:  Are  other  tasks  being  performed  at  least  in  part  between 
(T17-19)?  If,  for  example,  one  other  task,  FO  [N-IT^  (114-19)],  overlapped 

this  time  interval,  it  would  indicate  that  the  pilot  and  navigator  are  more 
thoroughly  occupied  than  the  copilot.  Assuming  that  the  subtask  had  not  been 
assigned  and  that  an  analysis  of  the  facets  involved  indicated  that  it  could 
be  performed  by  any  of  the  three  positions,  then,  all  other  factors  being 
equal,  the  logical  choice  for  this  additional  subtask  would  be  the  copilot. 
However  other  factors  might  mitigate  against  this  choice.  If  so,  this  could 
also  be  determined  by  using  the  symbolic  method. 

The  symbolic  information  below  the  horizontal  line  refers  to  equipment.  The 
equipment  symbols  are  E  =  Equipment,  MC  =  Major  component,  C  -  Component, 

A  =  Assembly,  SA  =  Subassembly,  and  P  =  Part.  When  the  equipment  symbol (s)  is 
enclosed  in  parentheses,  it  indicates  the  equipment  unit(s)  involved  in  the 
task.  When  E  appears  by  itself,  the  equipment  unit{s,i  affected  by  a  proposed 
change  has  yet  to  be  determined.  When  E  is  followed  by  one  or  a  series  of 
letters  divided  by  hyphens,  it  indicates  that  these  are  the  equipment  unit(s) 
that  may  be  affected  by  a  proposed  change.  For  example,  E-C-A  indicates  that 
an  assembly  to  a  component  may  be  affected. 

To  describe  a  change  and  its  effect  to  a  task,  additional  symbols  are  added 
after  the  brackets.  If  the  problem  were  to  determine  how  reliability  of 
performance  is  affected  by  a  reduction  of  5  minutes  to  task  time  in  the  orig¬ 
inal  example,  the  task  statement  would  now  read: 

C-5A-F0c  [PCN-CT3  (T15-25)]  (-TS)=R 

£ 

The  change  to  a  task  statement  always  appears  after  the  brackets  and  is  en¬ 
closed  ' n  parentheses.  In  this  example  (-T5)  indicates  a  reduction  of  5  in 
the  time  to  perform  the  task.  The  symbols  appearing  after  the  equal  (=) 
sign  are  applied  to  information  about  the  effects  of  proposed  changes.  If 

more  than  one,  they  are  separated  by  hyphens.  In  this  example,  R  *  Reliabil¬ 

ity. 

Changes  of  a  broad  and  far-reaching  nature  can  also  be  expressed  symbolically. 
If  there  is  no  symbolic  data  enclosed  within  tie  brackets  [  ],  it  indicates 
that  the  proposed  change  produces  no  effects.  If  the  change  statement  does 
not  include  symbols  for  mission  segment,  it  means  that  the  change  affects 
the  entire  phase.  If  the  symbols  for  phase  are  also  missing,  it  indicates 
that  the  change  affects  the  entire  system. 

To  reiterate,  the  use  of  symbolic  expressions  provide: 

•  A  concise  method  for  expressing  task  data 

•  A  concise  method  for  describing  changes  to  ta:k  data  an d  for  describing  the 

conditions  surrounding  these  change 

•  A  method  for  determining  tne  effects  of  changes  and  how  to  rectify  conflicts 
arising  from  these  changes 


I 
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*  A  simplified  and  exacting  method  for  requesting  information  from  computer 

storage 

•  A  method  for  saving  time 


SUMMARY 

In  summary,  the  type  of  faceted  classification  scheme  proposed  to  handle  human 
factors  task  data  is  one  that:  (a)  has  homogeneity  of  concepts  occurring 
within  the  same  category,  facet,  or  subdivision;  (b)  has  a  one-pla  e-per-con- 
cept  philosophy;  (c)  stresses  the  synthetic  capactiy  of  terms  to  combine  with 
one  another  to  exoress  more  complex  terms;  and  (d)  provides  the  capability  to 
express  functional  relationships  between  certain  data.  By  providing  the  sys¬ 
tem  with  a  category  framework ,  it  is  simple  to  assign  unique  placement  tc 
concepts  occurring  in  the  schedule';,  since  they  are  classified  according  to 
their  basic  characteristics 

The  vocabulary  that  results  from  faceted  analysis  can  be  used  for  initial  in¬ 
dexing  and  for  querying  the  data  base.  Facet  hierarchies  can  also  facilitate 
the  conduct  of  generic  searches.  It  will  be  simpler  and  less  costly  to  con¬ 
struct  and  use  a  facet  classification  system  than  an  enumerative  system. 

Also,  facet  analysis  provides  a  teennique  of  vocabulary  construction  that  has 
the  advantage  of  being  explicit  and  can  oe  precisely  described,  communicated, 
taught,  and  analyzed.  It  can  also  he  readily  changed  to  accommodate  modi¬ 
fications  and  deletions. 
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SECTION  VII 


DATA  ANALYSIS  AND  SIMULATION  TECHNIQUES 


INTRODUCTION 


The  techniques  employed  by  human  factors  specialist  in  refining  task  infor¬ 
mation  into  useful  products,  such  as  manning  estimates  or  the  determination 
of  skill  requirements,  are  often  the  result  of  analytical  and  simulation  pro¬ 
cedures.  Such  procedures  are  highly  amenable  to  computer  application.  It 
follows  that  if  data  are  easily  accessible  from  computer  storage,  various  tech¬ 
niques  -an  be  applied  to  refine  the  data  into  needed  products.  Research  on 
analysis  and  simulation  was  conducted  to  determine  tne  needs  of  aerospace 
system  programs  and  the  analysis  and  simulation  software  design  necessary  for 
integration  in  a  user-oriented  computerized  task  data  handling  system.  Pre¬ 
liminary  research  conducted  by  Hannah  et  al.  (1965)  and  Whiteman  (1965)  in 
dicated  that  anticipated  users  of  analysis  and  simulation  teenniques  extended 
from  program  level  managers  to  non-manageri al  specialists  in  aerospace  sys¬ 
tem  development  programs.  Hannah  et  a  1 . ( 1 965 )  concluded  that  computers 
were  not  being  used  m  many  instances  for  the  purpose  of  analysis  and  simu¬ 
lation  because  of  the  high  cost  of  computer  technique  development,  the  ex¬ 
tensive  time  required  in  the  programming  effort,  or  the  inaccessibility  of 
computers.  They  also  concluded  that  current  trends  in  the  application  cf 
analysis  and  simulation  techniques  in  aerospace  system  design  and  develop¬ 
ment  have  resulted  in  the  generation  of  many  diverse  techniques  that  are 
specific  to  particular  systems.  Thus,  the  question  for  research  was:  Can 
analysis  and  simulation  techniques  be  developed  that  wili  provide  for  the 
maximum  numbers  of  users  with  the  maximum  levels  of  application  and  speci¬ 
ficity.  This  approach  would  reduce  cost  and  time  by  eliminating  redundant 
development  of  analysis  and  simulation  techniques  and  computer  porqrams. 

The  current  and  potential  uses  of  computers  for  ducting  analysis  and 
urodui*  simulation  were  assessed  through  the  distribution  of  questionnaires 
during  the  preliminary  research  period  (Hannah  et  al .  ,  1965).  Many  resoon- 
dents  to  the  questionnaire  indicated  that  simulation  functions  were  either 
being  performed  in  their  organ i zati ons  or  could  be  performed  for  determining 
human  performance  estimates ,  equipment  performance  estimates,  manning  esti¬ 
mates,  hardware  requirements,  and  cost  estimates  Computerized  simulation 
techniques  have  also  facilitated  the  design  and  development  of  training 
devices,  the  investigation  of  various  subsystems  within  systems,  and  the 
estimation  of  system  reliability. 

whiteman  ,1965)  indicated  that  almost  one-half  of  current  computer  processing 
is  oevoted  to  analysis.  As  the  case  of  simulation,  it  was  shown  that, 
there  was  al'o  a  d;vers;tv  in  the  application  of  analytic  techniques.  How¬ 
ever,  in  analysis  the  redundancy  is  not  in  the  development  of  analysis  tech¬ 
niques,  but  rather  in  the  development  of  computer  programs.  Typical  analy¬ 
sts  are.  multiple  regression,  correlation  analysis,  factor  analysis,  and 
analysis  of  variance.  Techniques  need  to  be  developed  that  allow  a  user  to 
access  analysis  programs ,  such  as  these,  or  to  develop  his  own  techniques  in 
a  user-oriented  environment. 


With  regard  to  simulation,  Whiteman  (19fS)  recrimended  the  development  of  a 
computer  language  especially  oriented  to  human  factors  data.  The  language 
should  provide  facilities  for:  (1)  selecting  data  from  a  master  data  file, 
(2)  processing  selected  data,  and  (3)  generating  reports.  In  view  of  cur¬ 
rent  research,  the  question  of  concern  is  the  feu^.bility  of  producing  a 
simulation  language  that  is  tailored  to  human  factors  information.  This 
cculd  be  achieved;  however,  it  would  be  very  costly  due  to  the  extensive  man 
hours  necessary  to  produce  such  a  tool.  Current  '•esearch  found  that  there 
are  many  simulation  languages  already  in  existence.  Thus,  existing  simu- 
lati  on  languages  should  be  evaluated  and,  if  possible,  one  should  be  chosen 
that  complies  with  those  attributes  WMteman  recomnended. 

The  initial  effort  beyond  the  preliminary  research  approached  this  problem 
by  examining  task  data  for  their  fundamen;al  analytical  properties.  This 
effort,  reported  in  Potter  et  a  1 . ( 1 966 )  dealt  primarily  with  the  human  fac¬ 
tors  task  data  to  be  included  in  the  experimental  data  pool.  Several  prob¬ 
lems  were  investigated:  identification  of  the  quantitative  and  qualitative 
characteristics  of  the  data,  identification  o^  the  measurement  characteris¬ 
tics  of  data,  selection  of  standard  mathematical  measurement  units  (English 
vs.  metric  units),  and  identification  of  interfaces  with  other  research 
areas,  such  as  data  classifiration  and  vocabulary  standardization.  Final 
solutions  to  these  problems  must  be  souynt  in  conjunction  with  the  overall 
development  of  objectives  and  detailed  speciT ications  for  PSES  analysis  and 
simulation  functions. 


OBJECTIVES 


The  research  was  intended  to  answer  questions,  such  as: 

•  Do  current  analysis  and  simulation  techniques  lend  themselves  to  pooling 
into  a  generalized  data  handling  system  within  a  user-oriented  environ¬ 
ment? 

•  Is  it  possible  to  develop  a  general  simulation  technique  or  should  a 
store  of  simulation  techniques  be  provided7 

•  Can  analysis  and  simulation  techniques  be  incorporated  as  an  integral 
function  of  a  user-orientud  data  handling  system7 

•  Can  general' zed  analysis  and  simu1  atior.  techniques  in  a  user-oriented 
computer  environment,  lessen  the  need  to  continuously  develop  ystem-spe- 
cific  techniques? 

•  Can  the  data  base  cement  and  computer  programs  provide  ready  access  of 
Information  for  both  analysis  and  simulation? 

•  Must  modular  routines  be  used  to  provide  ready  access  of  information  fcr 
both  analysis  and  simulation? 

•  Must  new  techniques  be  developed  in  order  to  provide  an  analysis  and  s’^u 
lation  requirement  within  a  user-oriented  ca  puterized  data  handling  en- 
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vi ronment? 


*  Are  there  other  research  areas  that  have  significant  implication  upon  the 
development  of  analysis  ana  simulation  techniques  within  a  data  system, 
such  as  data  organization  and  vocabulary  control? 

These  questions  led  to  the  generation  of  the  following  research  objectives: 

*  Investigate  current  analysis  and  simulation  techniques  and  their  applica¬ 
bility  to  a  computerized  data  handling  system  in  a  user-oriented  environment 

*  Define  the  categories  of  data  for  analysis  and  simulation  which  provide  the 
input  to  analysis  and  simulation  techniques 

*  Select  an  analysis  and  simulation  technique  which  would  interface  with  the 
relevant  data  handling  research  efforts  and  tne  system 

*  Develop  standard  data  formats  that  are  amenible  to  analysis  and  simulation 
techni  ,,ues 

*  Develop  generalized  analysis  and  simulation  techniques  that  are  flexible 
enough  to  satisfy  the  needs  of  aerospace  system  development  programs 

APPROACH 

A n  a  iv 5 i  s 

An  analytic  capability  -ust  be  provided  as  an  integral  fu'-ct  <on  of  the  total 

user-oriented  data  handling  system  i f  r^e  ob  iect’ves  of  the  research  are  to 

be  realized.  Specifications  must  be  de. eloped  that  deal  wi th  the  sources  of 
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Figure  14.  Analysis  Concept 


drawn,  then  the  additional  data  pools  must  be  similar  in  organization  to  the 
first  data  pool  for  the  particular  system.  These  additional  data  pools  might 
contain  information  from  analyses  performed  on  other  ''stems,  which  are  simi¬ 
lar  to  the  system  being  developed.  This  is  an  effort  to  maintain  continuity 
between  different  data  bases  that  contain  information  relevant  to  a  single 
aerospace  system  development  program. 

The  second  source  of  input  is  users.  A  user  might  choose  to  perform  analvsis 
on  information  which  is  not  contained  in  an  existing  data  pool.  The  desire 
would  be  to  provide  a  capability  for  users  to  input  data  on-line. 

The  third  source  of  input  is  from  simulation.  After  outputs  have  been  derivpd 
from  a  simulation,  there  may  be  a  desire  to  analyze  these  outputs.  Changes 
in  values  ma_,  result  from  simulation  and  these  resultant  cnanges  could  be 
identified  for  input  into  an  analytic  data  file.  The  analytic  data  would 
contain  resu’ts  of  various  analyses  and  simulations  and  the  formulas  from 
which  the  results  were  derived. 

Just  as  there  are  several  sources  of  input  to  analysis  there  are  also  several 
recipients  o*  analytical  outputs.  As  shown  in  figure  14  s  the  recipients  of 
outputs  are  the  sybiem  users,  the  analytic  data  base,  and  s i mi  tion.  In  a 
gross  sense,  all  outputs  are  received  by  users,  since  the  results  of  analysis 
are  performed  because  they  are  desired  by  a  user.  The  outputs  of  analysis 
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serve  as  feedback  to  a  user  by  providing  easy  and  rapid  access  to  data  upon 
which  decisions  can  be  made. 

The  second  recipient  of  analysis  output  is  the  analytic  data  base  content  which 
represents  a  subset  of  data  chosen  for  analysis  from  a  data  pool.  Those  val¬ 
ues  derived  from  the  application  of  analysis  a-e  entered  into  the  data  base 
whenever  a  user  desires.  They  can  be  entered  as  new  element  values  or  used  to 
update  existing  values  of  elements. 

The  third,  and  perhaps  the  most  important  recipient  of  analyzed  data  in  terms 
of  demonstrating  the  integrated  concept  in  a  user-oriented  environment,  are 
the  simulation  routines.  To  illustrate,  the  values  obtained  from  logical, 
arithmetic,  or  statis  i cal  operations  might  be  obtained  from  the  analysis  pro¬ 
grams  and  used  as  inputs  to  the  simulation  programs.  If  these  obtained  val¬ 
ues  have  air  ady  been  processed  in  a  manner  which  is  amenable  to  simulation 
input,  there  would  be  no  need  for  users  to  generate  processed  data  for  simu¬ 
lation  input.  Users  could  elect  to  input  the  pre-processed  value  directly 
into  the  simulation  by  use  of  a  program  that  would  call  these  values  into  the 
simulation  program  thus  eliminating  one  additional  possibility  for  human  error. 

The  concepts  described  above  established  preliminary  specifications  for  se¬ 
lecting  a  set  of  analyses  programs  that  lend  themselves  to  integration  in  a 
user-oriented  environment.  The  selected  programs  must  be  investigate  for 
their  compatibility  with  the  software,  the  hardware,  the  philosophy  f  a 
user-oriented  environment,  and  the  needs  of  human  factors  specialists.  If 
an  analysis  technique  is  to  be  selected  for  implementation  in  a  user-oriented 
environment,  it  must  be  compatible  with  the  concept  of  time-sharing;  not 
restricted  to  implementation  on  any  specific  computer;  have  a  capability  of 
handling  data  stored  in  a  large  data  file;  be  relatively  easy  to  operate; 
provide  a  capability  to  process  logical,  arithmetic  or  statistical  operations; 
and  be  written  in.  the  JOVIAL  language  in  order  to  be  compatible  with  the  com¬ 
puter  language  of  RSES. 

The  investigation  led  to  a  system  which  hopefully  would  meet  the  requirements 
established  in  the  approach  and  the  objectives.  This  system  is  TRACE  III, 
presently  being  developed  by  System  Development  Corporation. 

TRACE  III  operates  in  a  time-shared  mode  and  has  a  specially-designed  user- 
oriented  command  language  that  provides  manipulation  of  analytic  data.  It 
provides  a  means  for  users  tc  organize  data  in  a  manner  which  is  most  appro¬ 
priate  to  their  specific  analytic  needs.  This  capability  in  TRACE  III  pro¬ 
vides  for  rapid  access  from  the  data  pool  of  the  specified  data  upon  which  a 
particular  analysis  is  performed.  TRACE  III  reduces  the  total  computer  pro¬ 
cessing  time  by  restricting  the  operation  to  subsets  of  data  elements  nec¬ 
essary  for  a  series  of  specific  analyses.  It  is  necessary  to  construct  a  data 
file  according  to  TRACE  III  specifications  in  order  to  perform  analyses  on 
those  data  called  from  the  larger  TRACE  III  file  and  placed  on  a  smaller  file. 
It  also  provides  an  automatic  updating  capability  that  fulfills  the  user's 
need  tor  manipulating  his  most  current  information  and  permits  him  to  in¬ 
clude  the  results  of  prior  analysis  in  future  manipulations.  These  capa¬ 
bilities  in  TRACE  III  fulfill  the  analytic  requirements  of  retrieving  data 


from  a  data  pool  and  allowing  users  to  input  data  not  contained  in  a  data  pool. 
There  is  also  the  possibility  of  d  sloping  a  capability  that  permits  the  user 
to  input  results  from  simulation  processing.  Through  these  processes,  TRACE 
III  provides  the  users  with  the  capability  to  interact  with  the  analytic  pro¬ 
gram  in  a  user-oriented  environment.  Some  of  tne  capabilities  of  tne  TRACE 
III  analysis  system  include:  (1)  a  system  of  computer  programs  operating  in 
a  time-sharing  mode,  (2)  performance  of  data  manipulation  functions  normally 
assigned  to  a  data  clerk,  such  as  the  derivation  of  new  variables  from  exis¬ 
ting  variables,  (3)  automatic  updating  of  the  data  base  with  derived  infor¬ 
mation,  and  (4)  data  manipulation  without  the  time-consuming  task  of  writing 
specific  programs  for  this  purpose.  TRACE  provides  the  capability  to  perform 
often-used  statistical  operations  and  permits  the  expression  of  more  complex 
and  less-usod  operations  without  any  programming  effort.  These  analyses  are 
expressed  by  the  user  in  the  simple  format  of  the  TRACE  III  command  language. 
Once  analytic  routines  are  written  by  a  user,  they  can  be  stored  in  a  file 
for  later  recall.  This  feature  exemplifies  another  reduction  in  time  ex¬ 
pended  by  the  users  in  processing  their  data.  TRACE  III  provides  an  analytic 
capability  which  can  be  considered  as  part  of  a  total  data  handling  system. 

It  allows  the  three  sources  of  input  discussed  earlier  to  interact  with  its 
programs  in  a  manner  which  is  quite  desirable  and  would  meet  many  of  the  re¬ 
quirements  of  aerospace  system  development  programs.  Conversely,  the  results 
derived  from  analysis  can  be  distributed  to  the  three  recipients  of  analytic 
output. 

In  addition,  there  are  two  communi cation  options  by  which  users  may  specify 
their  requirements.  The  users  can  operate  TRACE  III  using  either  its  command 
language  or  its  discursive  language.  The  latter  method  of  addressing  the 
system  leads  the  user  step  by  step  through  the  process  of  specification.  Af¬ 
ter  the  process  is  specified,  using  the  discursive  language,  the  command  lan¬ 
guage  corresponding  to  that  process  is  presented  to  the  user  and  passed  on 
to  the  TRACE  III  compiler  automatically.  The  TRACE  III  system  instructs  the 
user  in  the  construction  of  short,  precise  requests. 

In  summary,  the  TRACE  III  system  provides  an  analysis  technique  which  can  be 
used  in  a  user-oriented  environment.  It  permits  users  to  express  formulas  in 
a  manner  which  does  nor  require  programming  effort  by  the  user  and  is  simple 
to  operate.  It  allows  users  a  greater  interaction  with  the  data  and  is  de¬ 
signed  to  be  compatible  with  the  time-shared  PSES.  A  user  is  not  restricted 
to  rigid  preprogrammed  analysis'  rather,  through  the  command  language  of 
TRACE  III,  he  will  be  allowed  to  express  logical,  arithmetic  or  statistical 
operations  of  any  complexity.  It  also  support  the  concepts  envisioned  in  the 
analytic  approach  and  should  be  considered  for  mnrp  thorough  investigation  as 
the  possible  technique  to  be  inplementeo  in  the  PSES. 

Simulation 

Experience  has  demonstrated  that  simulation  capabilities  generated  for  one 
system  often  cannot  be  readily  applied  to  other  systems  or  even  different 
developmental  phases  of  the  same  system.  In  developing  a  simulation  capa- 
oility,  one  of  the  fundamental  questions  to  be  answered  is:  What  is  the  ob¬ 
jective  to  be  fulfilled  by  simolati  ?  Idea 'My,  a  general  simulation  capa- 
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bility  should  be  applicable  to  the  resolution  of  a  broad  spectrum  of  problems, 
such  as: 

•  Determination  of  the  requirements  for  selection  and  training  of  system 
personnel 

*  Evaluation  of  man's  roll  and  effectiveness  in  systems  and  subsystems 

#  Evaluation  of  man's  capacities  in  varying  environmental  situations 

*  Determination  o+'  the  procedures  and  requirements  in  regard  to  personnel, 
opeiation,  und  maintenance  needs 

The  development  of  a  simulation  capability  that  would  ^esolve  the  multiplicity 
of  problems  that  are  encountered  in  aerospace  system  development  programs 
should  be  considered  a  long-range  goal.  However  the  iimediate  goal  should  be 
the  development  of  a  limited  simulation  capability  that  is  meaningful  and  in 
consonance  with  the  other  developmental  activities  of  the  PSES  research  pro¬ 
gram. 

One  of  two  basic  approaches  can  be  followed  in  the  development  of  a  simulation 
capability;  a  closed-end  approach  or  an  open-end  approach.  The  closed-end 
approach  is  illustrated  in  figure  15. 


Figure  15.  Closed-End  Approach  to  Simulation  Development 


The  horizontal  arrows  in  figure  15  represent  simulation  processing  techniques 
which  are  developed  in  parallel  dependent  increments  from  the  initial  state 
through  the  first  and  second  stages  to  complete  development  of  the  simulation 
processing  techniques.  In  this  approach,  the  simulation  processing  tech¬ 
niques  are  nor  independent  of  each  other.  Since  no  one  technique  is  started 
or  completed  before  all  the  techniques  are  started,  fhe  work  effort  remains 
at  the  same  level  of  development.  Because  of  the  development  of  all  the 
simulation  processing  techniques  and  the  interfaces  between  them  take  place 
concurrently,  as  represented  in  figure  15  by  the  vertical  arrows,  the  incor¬ 
poration  of  a  new  simulation  processing  technique  into  the  simulation  pro¬ 
gram  may  require  extensive  expenditures  of  time  and  funds.  Therefore,  this 
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approach  presupposes  that  all  the  simulation  processing  techniques  are 
defined  and  their  algorithms  known  before  initiating  development  of  the 
simulation  system.  The  advantage  of  this  approach  is  in  resolving  well- 
defined  problems.  In  thi .  case,  all  work  and  cost  expenditures  are  chan¬ 
neled  Into  a  concerted  effort  to  promote  the  resolution 'of  the  problem. 

The  open-end  approach  is  illustrated  in  figure  16. 


Initial 


(Processors) 


(Processes  added) 


(Processes  deleted 
and  replaced) 


Figure  16.  Open-End  Approach  to  Simulation  Development 


The  open-end  approach  involves  postulating  simulation  goals  and  developing 
simulation  processing  techniques  and/or  selecting  simulation  processing  tech¬ 
niques  from  off-the-shelf  inventories  that  can  be  used  to  achieve  the  stip¬ 
ulated  goal.  Each  processing  technique  incorporated  into  the  simulation  pro¬ 
gram  is  independent  of  every  nther  processing  technique  and  a,  j  intercom¬ 
munication  of  information  between  the  techniques  utilizes  the  user  as  the 
communication  channel.  In  this  approach,  different  process  inn  techni  s 
for  each  established  goal  can  be  in  various  staqes  of  develooment.  The 
development  of  each  simulation  processing  technique  can  be  correlated  to 
the  state-of-the-art  in  simulation  technology,  the  incorporation  or  new  in¬ 
formation  items  into  the  data  pool,  j.  ast  experie'-  e  gained  from  users  con¬ 
cerning  the  utility  of  each  simulation  technique,  changes  m  user  needs  and 
requirements,  and  funds  available  for  development.  Furthermore,  the  addition 
of  new  processing  techniques  can  be  undertaken  at.  a  relatively  low  expen¬ 
diture  of  time  and  funds  oeca^e  of  the  lack  of  utomatic  cross-communications 
between  processing  techniques. 

One  major  simulation  problem  can  be  illustrated  by  considering  its  solution 
through  the  application  of  these  two  approaches.  This  is  the  problem  of  data 
acquisition  and  selective  retrieval  for  simulation.  Selective  retrieval  of 
data  specifically  for  simulation  is  the  firs*  prerequisite  for  any  simulation 
program.  The  data  must  be  structured  and  organized  in  a  manner  acceptable 
for  input  into  the  specific  simulation  processing  program.  This  structuring 
can  oe  accomplished  either  by  organizing  the  computer  file  structure  in  ac- 
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figure  18.  Example  of  Open-End  Approach  to  Simulation 


In  this  approach  the  operational  system  would  consist  of  a  structure  of  soft¬ 
ware  rroorams  that  provide  a  file  of  rot»->?v’Me  data  organised  in  accordance 
with  user  speci f i - .  ti ons .  These  data  are  then  processed  by  generalised  user 
specified  simulation  procedures  (program).  Under  this  concept  the  user  loses 
a  specificity  that  prohibits  the  accomplishment  of  some  inflations;  however, 
he  oains  a  flexibii;ty  that  enable  him  to  structure  simulation  procedures 
capable  of  meet  inn  most  of  his  requirements. 

A  possible  disadvantage  of  the  open-end  approach  is  that  the  user  must  know 
the  limitations  and  requirements  of  each  simulation  processing  technique  and 
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may  have  to  accomplish  a  significant  amount  of  manual  labor  to  effect  noise- 
free  communications  between  processors,  particularly  when  the  answer  to  a 
query  requires  the  operation  of  a  sequence  or  simulation  processing  tech¬ 
niques.  However,  once  the  user  has  been  satisfied  that  a  set  of  simulation 
processing  techniques  has  demonstrated  utility  and  validity,  further  develop¬ 
ment  of  this  set  of  techniques  can  be  undertaken  to  approach  closed-end 
development. 

Of  the  two  approaches,  the  open-end  approach  has  greater  intrinsic  appli¬ 
cability.  The  development  requirements  to  atUin'the  goals  established  in 
this  research  must  be  considered  as  interactive  and  evolutionary.  Since  all 
ramifications  of  a  system  and  users  needs  or  requirements  cannot  be  predicted, 
the  opt  i-end  approach,  which  allows  for  growth  and  expansion  at  relatively 
minimum  expenditure  of  funds  and  time,  is  recommended  for  consideration  in 
the  further  development  of  the  PSES. 

In  concept,  the  developmental  process  should  be  for  the  purpose  of  selecting 
a  set  of  tools  to  be  used  in  a  simulation  system.  In  this  case,  a  tool  is 
analogous  to  a  simulation  processing  techn:]ue,  the  central  location  is 
analogous  to  computer  storage.  The  tools  selected  must  depend  upon  the  use 
to  be  made  of  them. 

The  simulation  technique  selected  must  be  adaptable  to  the  computer  system 
that  is  to  be  used.  This  task  may  eru.ail  a  relatively  small  amount  of  time 
If  the  technique  Is  already  written  in  some  general  purpose  language,  such 
as  Fortran,  JOVIAL,  or  COBOL.  In  this  case,  recompiling  thr^jgh  a  trans¬ 
lator  may  be  sufficient.  If  the  technique  is  available  in  a  machine-lan¬ 
guage  code,  mors  time  may  be  required  for  its  adaptation.  If  the  technique 
is  ii  the  natural  language,  considerable  time  may  be  required  to  adapt  the 
language  to  the  acceptable  program  form  and  to  test  and  check  out  the  pro¬ 
gram.  At  leas;  each  input/output  routine  should: 

•  Provide  an  interactive  capability  to  display  *ixed  outputs  as  the  result 
of  the  operations  of  the  simulation  techniques.  The  user  should  also  be 
able  to  specify  changes  of  ovent  ordering,  within  the  fixed  output  capa¬ 
bility,  whenever  the  technique's  output  can  be  so  ordered. 

•  Provide  a  capability  to  permit  the  user  to  input  and  store  data  that  are 
not  contained  in  the  data  pool  but  that  are  relevant  to  the  operation  of 
the  processor  to  be  used. 

•  Provide  a  capability  to  store,  on  tape  or  binary  disc,  any  grouping  of 
data  and  processors  that  the  user  may  wish  to  save. 

A  capability  to  extract  data  from  t  e  data  pool  and  organize  them  in  a  form 
suitable  for  use  by  a  simulation  program  is  extremely  necessary  before  per¬ 
forming  simulation.  The  extraction  should  be  accompl  i shed  by  "the  users  thus 
allowing  data  to  be  reorganized  by  event  orderings,  e.g.,  time,  task,  location, 
operator.  For  example,  it  may  be  necessary  to  provide  a  time-line  analysis 
of  the  data  before  performing  a  simulation  (see  Appendix  XI !) .  Data  reorga¬ 
nization,  based  on  some  type  of  event  ordering,  car,  enable  use^s  to  deter¬ 
mine  the  necessity  for  providing  add.  .ional  data  befor  beginning  a  simu¬ 
lation  process.  Research  has  shown  that  although  time-lining  is  not  simu- 
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lation,  it  is  a  necessary  starting  point  in  the  development  of  a  set  of  simu¬ 
lation  programs.  This  philcophy  is  not  necessarily  valid  if  a  variety  of 
simulation  processes  are  to  be  used  to  solve  human  factors  problems  in  aero¬ 
space  system  development.  However,  if,  as  has  been  indicated,  one  simulation 
language  and  one  set  of  simulation  processes  are  developed  to  serve  the  gen¬ 
eral  needs,  then  it  is  a  very  valid  and  necessary  function  that  aids  in  the 
development  of  this  latter  capability.  When  the  contents  of  the  data  pool 
have  been  expanded  to  include  all  of  the  input  requirements  for  the  spectrum  of 
simulation  processing  techniques  necessary,  the  event  ordering  formatting 
capabilities  will  no  longer  be  required.  The  user  can  then  retrieve  the  data 
from  the  data  pool  and  input  these  data  directly  by  a  calling  program  which 
automatically  inputs  the  identified  data  in  simulation  processing. 

Under  the  provision  that  each  incremental  step  in  the  development  of  the  simu¬ 
lation  techniques  should  result  in  potential  user  benefits,  the  techniques 
initially  employed  should  be  in  line  with  user  needs  and  requirements.  How¬ 
ever,  the  initial  simulation  capabilities  should  also  be  considered  in  terms 
of  other  development  efforts  caking  place  in  the  PSES  program,  such  as  the 
data  pool  organization,  content,  and  vocabulary  (see  Sections  V  and  VI). 

The  output  of  a  simulation  run  should  be  in  a  format  compatible  with  the  user 
requirements.  D.  A.  Wilson  (!967),  of  the  U.  S.  Naval  Personnel  Research 
Activity,  San  Diego,  California,  has  developed  a  scheme  for  automating 
Operational  Sequence  Diagrams  (OSD).  The  OSD  is  a  specialized  form  of  task 
analysis  output  developed  by  the  U.  S.  Navy  (see  Appendix  XII).  This  method, 
with  some  minor  modifications,,  can  be  programmed  as  a  fixed  format,  output  of 
a  simulation  run  for  PSES.  Thus,  the  PSES  user  would  have  the  option  of 
requesting  that  the  results  of  his  simulation  be  output  in  either  a  fixed 
format  or  a  user-specified  ,'ormat  by  applying  the  COMPOSE  program  of  TDMS 
(see  Section  III). 

SUMMARY 

The  research  was  involved  with  the  feasibility  of  developing  an  overall  PSES 
analytic  and  sinulati  i  concept  that  would  wet  the  requirements  established 
for  an  operational  data  handling  system.  TRACE  III,  a  set  of  analysis  pro¬ 
grams  developed  by  SDC,  was  chosen  tor  investigation  to  determine  whether  it 
w  'uld  achieve  the  concepts  postulated  and  operate  within  the  constraints  of 
the  PSES.  By  providing  users  with  a  capability  to  operate  TRACE  III  in  the 
PSES  environment,  user  feedback  can  be  used  to  determine  whether  this  tool 
should  be  integrated  into  the  PSES. 

The  nethodolpgv  for  developing  a  simulation  capability  for  the  °SES  was  in¬ 
vestigated.  A  concept  for  developing  simulation  within  the  PSES  environment 
was  postulated  and  the  initial  steps  specified.  An  open-end  approach  was  re¬ 
commended  as  the  means  to  attain  the  initial  goal  because  it  affords  a  flex¬ 
ible,  economical,  and  expeditious  means  of  simulation  development. 

These  techniques  are  intended  to  enable  successful  research  into  man-machine 
problems  by  allowing  users  to  interpret  various  configurations  of  mar-machine 
interactions . 
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appendix  I 

SYS (EM  DATA  SOURCE  FORMATS 


***"»•- 


This  appendix  contains  sample  system  data  source  formats  used  in  generating 
the  experimental  data  pool  for  the  PSES.  These  formats  are: 

•  ALCC  -  Time-Line 

Task  Information  Summary  &  Task  Analysis  Work  Sheet 

•  C-5A  -  Task  Analysis  *ork  Sheet 

Requirements  Allocation  Sheet  ( PAS ) 


Formats  not  included  in  the  appendix  are: 

•  Link  analysis  (ALCC)  a  standard  presentation  of  Lin*  analysis 

configuration 

•  Drawings  (ALCC)  equipment  sketches  from  ^’Rl ,  engineering 

sketches  showing  approximate  'ocaticns  of 
equi  pment 


(C-5A)  aii craft  sketches  showing  loo at 


:  w  '  r.< 


(Saturn)  configuration  sketches  showing  sta*  :  r.xmber 

and  locations  of  entrance  hat  ohes 


•  Other  engineering  data 

■  ALSO ' 


I:  ts  or  c.necKout  tares  -m in:  rma. 
engineering  data 


prel  i x  i nary  es t  ir.at  es 
mai  nt  <-nan  ce  t  ho  no 


T  l* 
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BGD  Exhibit  65- 
13  May  196 5 


rASK  ANALYSIS  WORK  SHEET 


1.  DATE: 


2.  NARRATIVE  TASK  DESCRIPTION: 


PERFORMANCE  FACTORS  CHECKLIST 


FACTORS 


COMMENTS 


Moure  20.  TASK  ANALYSIS  WORK  SHEET 


••  Vli 

*;  V .  ’-Vl 


/ 


BSD  Exhibit  65~lt 
13  May  1965 


MEASUREMENT  TECHNIQUES: 


(  )  Observation 

v  )  Instrumentation 
{  )  Questionnaire 

(  )  Interview 

(  )  Paper  and  pencil  test 

(  )  Check  of  records  and  logs 

(  )  Other 

PROBABLY  ERROR  FACTOR: 

(  )  Unlikely 

(  )  High  (see  Comment) 

CONSEQUENCE  OF  DEVIATIONS: 


SPECIAL  HANDLING: 

Care : 

(  )  Little 

(  )  ons iderable  (see  Comment) 

(  )  Moderate 

Type: 

(  )  Manual 

l  )  Vehicular 
(  )  Crane 

(  )  Jack 

'AFETY  PRECAUTIONS : 

’Ounces  o i  Special  Danger: 

v  )  None 
•  )  Mechanical 

(  )  Electrical 

(  )  Explosive 


Pi  (jure  20  (Continued) 
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BSI)  Exhibit  65-14 
13  May  1965 


T.  SAFETY  PRECAUTIONS  (Cont) 

(  )  Volatile  Fuels 

(  )  Toxic  Substances 

(  )  Pneumatic 

(  )  Hydrauli c 

(  )  Temperature 

(  )  Fire 

Preparations : 

(  )  Clear  Area 

(  )  Protective  equipment  or  clothing 

(  )  Emergency  Standby  (personnel  and  equipment) 

(  )  Other  warning  signs  (see  Comments) 

8.  MANIPULATING  CONTROLS : 


Type: 


(  5  None 

(  )  Hand  Valves 

{  )  Push  Buttons 

(  )  Control  Auditory  Feed  Back 

(  )  Toggle  switches 

(  )  Selector  Switches 


Actuation  Error  Probability: 

(  )  Unlikely 

(  )  Certain  (see  Comment) 

(  )  Possible 


9.  NATURE  OF  PROCEDURE: 

(  )  Fixed 

(  )  Vari able 

(  )  Alternatives  specified  in  procedures 

(  )  Alternatives  selected  by  the  individual 

(  )  Motor  Skills 

(  )  System  Analysis 

(  )  Circuit  Analysis 


10.  SPECIAL  CLOTHING  USED: 


Figure  20  (Continued) 
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BSD  Exhibit  65-11* 
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EC HN I CAL  PUBLICATION  COVERAGE  REQUIREMENTS 

[  '  Equipment  Functional  Description 

(  )  Data  Flow  Diagram 

(  )  Schematics 

(  /  Drawing 

(  )  Numerical  Data 

(  )  Step-by-Ctep  Proce lure 

)  Other 
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a icc  tile  unesme 


REF.  NUMBER 


1.1 
1.1.1 
1 .1 .2 

1.1.3 

1.1.4 

1.1.5 

1.1.6 

1.1.7 

1.1.8 

1.1.9 

1.2 

1.2.1 

1 .2.2 


1.2,3-20 
1 .2.21 
1 .2.22 
1 .2.23 

1 .2.24 

1 .2.25 

1 .2.2 6 
1 .2.27 
1 .2.28 

1 .2. 25 ->52 


1.3 

1.3*1 

1.3.2 

1.3- 3 

1.3.4 

1.3.5 

1 .3.6 

1.3.7 

1.3.8 

1.3.9 

1.3- 10 

1.3.11 

1 .3.12 


RCY  UR 


1.0  ATTAIN  FLIGHT  REhDINES3 


FUNCTION 


Turn  On  Power 

Go  to  Circuit  Breaker  installation  -  ALCC  panel. 
Verify  all  circuit  breakers  are  el'-sed. 

Go  to  ALCC  POUR  SUPPLY  Unit 

Throv  POVER  switch  to  Off 

Go  to  Code  Retaining  Power  Unit 

Throv  Code  Retaining  Pover  Unit  ON/OFF  switch 

to  0!.’  position 

Verify  Code  Retaining  Power  Unit  display  is  Of.' 
Return  to  STA  1 

Confirm  POVER  ON  display  is  Off 
Perform  Lamp  Tests 

Rotate  4j4l"  and  STA  2  Lamp  test  thumbwheels 

to  zero 

Confirm  jfS's  in  multiple -legend  lamps  (The  flight 
Indicators  will  be  sequenced  A  tbru  J  and  K 
thru  T,  respectively) 

(Repeat  .1  L  .2  for  I's  thru  9'®) 

Rotate  lamp  test  thumbwheels  to  ALL 
Confine  all  single  legend  Imps  illuminated 
Rotate  lamp  test  thumb-  heels  to  OFF 
Confirm  all  lamps  are  OP? 

Depress  STA  1  Launch  Control  panel.  LAi  IP-TEST 
butter. 

Confirm  all  lamps  illuminated 
Release  lamp  test  button 
Confirm  nil  lacps  are  OF? 

Repeat  procedures  .i-.24  for  DATA  PROCESSOR 
panel  lamps 

Ih-'Aj  xe  rc_l  s  e_  Ts  p?. 

Unlock  tape  reader  door. 

Insert  tape  reel  and  Adjust 
Close  door  A  attach  two  padlocks 
Go  to  STA  l ,  Launch  Panel 
Depivss  A  lelenr.e  KILL  button 
Receive  status;  IN  PRCCE3S-  displ.  ON 
Receive  status;  IN  PIiOCESS  display  OFF, 

COMPLETE  display  Oil 
Depress  &  release  REWIND  button 
Receive  status;  IN  PROCESS  displ.  Off 
Receive  status;  IN  PROCIi'S  dir  .'lay  OFF, 

COMi’LLVK  die  play  ON 

Depnccs  &  release  MASTER  RESET  button,  CViPLETK 
display  OFF 

Report  to  Maintenance  A  Operations 

NOTE;:  Fault  light  will  be  "ON"  during  thin 
procedure. 

>  Dependent  upon  rcnJr.il  speeds  of  31"/see ,  assu:-.*.  n 
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1  -4l  >2 


1 -4l/2 


1 -4 1/2 ' 
1 -4l/2 
1 -4l/2 
1-4L/2 
1 -4L/2 
1-LP 


;  300 


IOC. 


CCCliP 

CCCBP 

ER2 

ER2 

BATT 

RATT 


I!  II  II  II  UJ  5 


I  v 

II  III  II  111  II 


'!  "'PC. 


CREW  TASK  ANALYSIS 


ADHAOTER  /  LOCATION 


CONTROL  DISPLAY  ACCESS/  /TASK  /  TIME-BREAKDCWN  ( SEC  ] 

/  /  / /  //felCLmslOI<  PEBFOmAMCE 


DIME-BUDGET 

:kps-min} 


Yw$z#y^y 


iwMrM 


nnytyiBirggugf5HgniB3Hif3fflE3B]fflB3B3EDE3BlB 


nssn 
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fessssSSaBS 

ISSSSSiSSSSiSKSSSSm 

issggiHgggnsssg 


CONTROL  DISPLAY 
ACCESS  CODES 

K-KXCRLIJPrT 

A-ACCEPTABLE 

M-KAKOINAL 

U-UIRATISFACTORY 


DIFFICULTY 

CRITICALITY 

FREQUENCY 

CODES 

CODES 

CODES 

1-NO  DIFFICULTY 

:=*T  HAZARDS 

O-ONCE  PER 

2-MIKOR 

P-POSSIBLE 

FLIGHT 

3-MODERATE 

HAZARDS 

F-AS 

R-very  diffi¬ 

3- EXTREME 

REQUIRED 

I 3 INTER- 

cult 

HAZARDS 

1-FAMILIAR! NA¬ 
TION 

D-DETAILED 

Y-EULLY 


MITTENT 

C-CONTINU* 

OUS 


ABOVE  CODES  PI  LATE  ”0  TASK  'HARACI 
SUBREOTL  N.' 


TO!. FRANCE 
HAZARD 

REMARKS 


APPENDIX  II 


INPUT  DATA  CONTENT  ANALYSIS 

ALCC 

C-5A 

SATURN 


LIST  OE  ABBREVIATIONS 

The  following  abbreviations  are  used  throughout 
this  Appendix  under  the  heading  "Source" 

PSES  -  Pilot  Study  Experimental  System 
TAWS  -  Task  Analysis  Work  Sheets 
T-L  -  Time-Lines 

PAS  -  Requirements  Allocation  Sheet 

QQPRI-  Qualitative  and  Quantitative  Personnel 
Requirements  Information 

HAA  -  Maintenance  Activities  Analysis  Sheet 

OR  -  Drawings 

LA  -  Link  Analysis 

0En  -  Other  Engineering  Data 

All  -All  Sources  Used 
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DEFINITION  OF  DATA  ELEMENTS  (LUCID) 


The  following  ia  an  alphabetized  list  of  all  the  data  elements  contained  in 
the  LUCID  data  based.  The  list  contains  the  definition  of  each  element  and 
idenxifies  the  data  base  vith  which  the  element  is  associated. 

AFSC  (ALCC,  C-5A)  --  contains  the  Air  Force  Specialty  Code  of  the  individuals 
required  to  perform  tasks.  If  more  than  one  type  of  person  is  required 
to  perform  a  given  task,  AFSC  contains  multiple  codes.  The  information  is 
alphanumeric  in  composition  and  contains  a  maximum  of  6  characters,  e.g., 

11*16,  1*3151E.  The  AFSC  is  not  accessible  by  its  individual  parts,  e.g., 
shredout,  skill  level,  career  field. 

CRITICALITY  (ALCC,  SATUP.N)  -  contains  the  degree  of  criticality  associated  with 
the  overall  performance  of  a  task.  For  SATURN,  the  information  is  presented 
in  descriptive  phrases  containing  a  maximum  of  approximately  150  characters . 

For  ALCC,  the  information  is  presented  in  the  following  codes. 

Code  Equivalent  Degree  of  Criticality 

A  Performance  failure  will  cause  an  abort 

resulting  in  equipment  damage  or  personnel 
injury. 

E  Performance  failure  will  cause  an  abort 

resulting  in  equipment  damage  and  no 
personnel  injury 

C  Performance  failure  will  allow  operation 

to  be  carried  out  but  not  within  planned 
limits 

D  Performance  failure  will  allow  operation 

to  be  carried  out  but  delated  beyond 
operational  tolerances 

E  Performance  failure  will  not  affect  successful 

operation 

S  Task  is  applicable  to  supporting  activities 

and  will  not  materially  affect  operations 

DIFFICULTY  (ALCC)  -  contains  the  degree  of  difficulty  associat'd  with  the  overall 
performance  of  a  task,  The  information  is  presented  iri  the  following  codes. 

Code  Equivalent  Decree  of  Difficulty 

G  Equipment  design  maxes  task  performance 

difficult 

P  Skill  or  knowledge  required  makes  personnel 

selection  and  training  difficult,  and  a 
high  probability  of  performance  failure 
is  anticipated. 

X  Other 


-116- 


ENTRY  DATE  (all)  -  contains  the  date  the  information  was  entered  into  the  data 
base.  The  date  is  presented  in  the  form  of  three  pairs  of  digits  that  represent 
year-month-day.  For  example,  670321  represents  March,  21,  1967. 

ENTRY  NUMBER  (all)  -  contains  a  unique  numerical  identifier  assigned  to  each 
task  as  it  is  entered  into  a  data  base.  The  identifiers  are  assigned 
sequentially  wi+Mn  each  system  and  contain  from  1  to  3  digits. 

ENTRY  TAPE  (all)  -  designates  whether  the  data  base  entry  describes  a  task  as 
originally  entered  into  the  data  base,  or  whether  the  entry  has  been  subse¬ 
quently  updated  in  response  to  modifies  ions  to  the  task.  If  the  task  has  not 
be  n  updated,  the  element  contains  the  value  NEW  ENTRY  in  ALCC  and  C-5A  and  the 
vo.-ue  NEW  TASK  or  NEW  FUNCTION  in  SATURN .  If  updated,  the  element  contains  a 
short  df  criptior  of  the  modification. 

EQUIPMENT  R 1 NIPJLABILITY  (  ’-5A)  -  indicates  how  well  an  individual  can  mani- 
p1  .ate  the  eq  ^pmenJ  utilized  in  performance  of  a  task.  The  information  is 
present  d  in  the  following  codes: 


Equivalent  Manipulabilit^ 

Excellent 
Acceptable 
Marginal 
Unacceptable' 

EQUIPMENT  REACHABILITY  (  C-5A)  -  indicates  how  well  in  individual  can  reach  the 
equipment  utilized  in  performance  of  a  task.  The  information  is  pre-  nted  in 
the  following  codes: 

Code 

E 

t 

M 


Equivalent  Reachabj lltv 

Excellent 

Acceptable 

Margi  rial 

Unaceep-  at le 


Code 

E 

A 

M 

U 


EQUIPMENT  READABILITY  (C- SA) 
display  surface,  gauge,  e*-~. 
information  is  presented 

..'ode 

E 

A 

M 


in  performance  of  the  task.  The 
ng  codes : 

Equivalent  Readabili  y 

Excel  ]  er.t 

Acceptable 

Mm  g :  nal 
Una overt at, ie 


indicates  how  v-II  an  individual  can  read  a 
util i zed 
in  the  followi 
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EQUIPMENT  VISIBILITY  (C-5A)  -  indicates  how  well  an  individual  c-  n  see  an  item 
Of  hardware  that  is  required  for  the  performance  of  a  task.  The  information 
is  presented  in  the  following  codes: 

Code  Equivalent  Visibility 

E  Excellent 

A  Acceptable 

M  Marginal 

U  Unaccep  able 

FUNCTION  (all)  -  indicates  that  portion  c''  a  t  ssion  profile  that  is  perform  i 
by  a  related  group  of  tasks.  The  infernal,  ioT  is  alphanumeric  in  composi  ion 
and  contains  a  maximum  of  72  characters. 

FUNCTION  CHECKOUT  TIME  (SATURN)  -  contains  ie  total  time,  expressed  In  minutes, 
to  perform  the  automated  operation  as  descr j Oe  in  the  function. 

FUNCTION  DESCRIPTORS  (SATURN)  -  contains  the  names  and  sequence  oi  tasks  hi  oh 
are  performed  if  a  failure  is  detected  during  the  automated  checkout. 

FUNCTION  START  TIME  (SATURN)  ~  contains  the  time,  in  minutes,  at  which  a 
function  begins.  Time  begins  with  a  large  negative  number  and  proceed0  m  2t.ro. 

FUNCTION  TIME  BUDGET  (SATURN)  -  contains  two  values  identifying  increments  or 
decrements  of  time,  in  minutes,  by  which  the  start  and  stop  times  :f  a  la  may 
be  altered  without  affecting  the  performance  of  a  task.  The  information 
alphanumeric  in  composition.  Example:  START  T-1.67  HR,  END  T-int  1C  MIN. 

HARDWARE  INFORMATION  (all)-  contains  the  names  or  designators  of  tht  hardware 
associated  with  a  specific  task.  The  information  is  alphanumeric  in  compos i tic 
and  contains  a  maximum  of  72  characters  for  each  item,  of  hardware. 


HAZARDS  (all)  -  contains  information  regarding  the  risk  associated  with  perform¬ 
ing  a  given  task.  The  information  is  alphanumeric  in  composition  arid  eo ..'tains 
a  maximum  of  72  characters  per  value. 

LOCATION  (all)  -  describes  the  physica  place  associated  w ' th  the  performar,‘e  of 
a  task.  Locations  range  from  specific  crew  work  stations  tor  operational  tasks 
to  field  maintenance  facilities  for  maintenance  tasks.  The  information  is 
alphanumeric  in  composition  and  contains  a  maximum  of  72  charactei 3 . 


MISSION  PHASE  (all)  -  contains  the  broadest  level  of  mission  pi  file 
information  of  a  task.  It  is  alphanumeric  in  composition  and  contains  a 
of  72  characters.  Typical  values  are  "preflight,"  "airborne,"  an.  "post 
operations . 


m  i  xi  mur. 

*  1  Ag,.  I 


MISSION  SEGMENT  (all)  -  contains  a  breakdown  or  the  mirr ion  phase  in  .-hi  ?h  a 
task  is  performed.  The  information  is  alphanumeric  in  composition  and  contains 
a  maximum  of  72  characters .  Typical  values  (for  the  mis  si  rhas-a  "a  r:  . 
operations")  include  "climb,"  "cruise,"  and" descend" . 
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PERFORMANCE  CRITICALITY  (C-5A)  -  contains,  for  each  individual  involved  in  the 
performance  of  a  task,  the  degree  of  criticality  associated  with  its  perfor¬ 
mance.  The  information  is  presented  in  the  following  codes: 

Code  Equivalent  Criticality 

1  No  Hazard 

2  Possible  Hazard 

3  Extreme  Hazard 

PERFORMANCE  DESCRIPTORS  (all)  -  contain  the  individual  man/machine  procedural 
steps  required  of  individuals  in  order  to  perform  a  specific  task.  Procedural 
steps  are  the  smallest  set  of  perceptions,  decisions,  and  responses  which  the 
human  must  perform  in  conducting  a  task.  Included  with  each  procedural  step 
.3  the  AFSC  or  NASA  designator  of  the  individual  or  individuals  performing  the 
operation  as  well  as  the  total  time  required  to  per fc. ui  uhe  procedural  step. 

The  information  is  alphanumeric  in  composition  and  is  generally  quite  lengthy. 

PERFORMANCE  DIFFICULT.  (C-5A)  -  contains,  for  each  individual  involved  in  the 
performance  of  a  task,  the  degree  of  difficulty  associated  with  the  performance 

e  information  is  presented  in  the  following  codes: 

lode  Equivalent  Difficulty 

1  No  difficulty 

2  Minor 

3  Moderate 


r  Fo  RMA  * '  C E  FR  EQUEN C  Y  ( ■ "  - h  A  )  -  indicates,  by  code,  how  often  each  individual 
nvolved  n  the  task  performs  his  assigned  duties. 

Code  Equivalent  Frequency 

0  Once  rer  flight 

H  As  required 

’  Intermittent 


PERT  _NNEL  NAME  ( all  /  -  contains  the  official  ti'ie,  e.g.  ,  pilot,  radio  rerairma 
f  pt\;  Uriel  involve4  in  the  performance  of  to  ,/.s.  A  name  exists  for  each 
”■  •> r s  nne  1  code  identified  for  a  task 


IT  VNN  •  . ’!M1TR  ■, all  contains  one  or  m  re  numeric  vhi 

mler  *  r.v*H'h  rerS' *  *  vr-e  re-^ui  rp*.i  t  :-  r-erf nt  a  task  . 


rer res e: 
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PERSONNEL  TIME  ( all )  -  contains  one  mort  times,  each  associated  with  a 
particular  personnel  type  and  identifies  the  amount  of  time,  in  minutes,  spent 
in  the  performance  of  a  task  by  each  of  the  personnel  types  involved  in  the 
task  . 


REMARKS  (all)  contains  the  revision  code  associated  with  the  last  revision 
of  ♦he  task.  The  information  is  expressed  by  a  single  lett.tr, or,  if  no 
revision  has  occurred,  the  word  NONE. 

REVISION  (ail)  -  contains  the  revision  code  associated  with  the  last  revision 
of  the  task.  The  info’-mation  is  expressed  by  a  single  letter,  or,  i*'  no 
revision  has  occurred,  the  word  NONE. 

SAFETY  PRECAUTIONS  (all)  -  contains  statements  regarding  precautions  tc  be  taker, 
during  the  performance  of  a  task.  The  information  contains  a  maximum  of  055 

characters . 


SOURCE  IDENTIFICATION  (all)  -  contains  the  author ,  document  references,  origin¬ 
ating  organization,  security  classification  and  date  associated  with  the 

analysis  of  a  task. 

SPECIAL  SKILLS  ;C-S A)  -  conts  ns  statements  Identifying  v*  ruai  ,  verbal, 
preceptual,  motor,  Judgmental  capabilities  and  the  knowledge  of  theory  required 
by  individuals  to  properly  perform  a  task 

SPECIAL  TOOLS /EQUIPMENT  \&ll)  -  contains  the  items  of  equipment  required  to¬ 
per  form  a  task.  Each  item  contains  a  -aximum  of  72  characters. 

b'AR^  'TIME  (C-SA)  contains  the  time,  in  mii.utes ,  at  which  a  task  begins.  For 
C-5A,  time  is  calculated  chronologically  from  the  start  of  the  rrefligh1  phase, 
beginning  at  tire  zero  and  continuing  until  the  end  of  the  post-flight  phase . 

STOP  TIME  (C-5A)  -  contains  the  stop  time,  in  minute? ,  associated  with  *h» 
performance  of  a  task.  The  time  is  referenced  ohronol  vi rally  frcrr.  the  start 
of  the  preflight  phase,  which  is  identified  as  time  zero. 

TASK  (all)  -  contains  the  name  of  the  task  being  ’escribed.  The  'ask  :s  the 
basic  performance  'unit  of  a  mission  profile.  It  is  a  grouping  of  pr..ce  lural 
steps  that  specify  the  individual  human  actions  required  t.  -■  per!'-- nr.  the  t  -tsk , 
The  task  name  contains  a  maximum  of  72  characters  with  -<r.:y  minor  extent :  -r.s . 


TASK  FREQUENCY  (ail)  -  describes  how  often  a  task  is  performed.  The  inf 
is  alphanumeric  anq  contains  values  such  as  "or.  re  per  flight  "as  recui  ?  e  .1" , 

and  "twite  per  mission," 


TOTA^,  TASK  TIME  (all)  -  contains  the  total  time, 

a  task . 


TRAINING  REQUIREMENTS  (ALCC,  £ 
ments  necessary  for  each  pers 


n  n  **  1  '  vr  t* 


f  i  (>  g  *.  V-  o  <5  n 

:  r.vo  ved  i 
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l)  Object  System: 


2)  Date/Revision: 


3)  Security  Classification 


b) 

~G) 

10) 


Orignuting  Organization  I  5)  Author/ Do*,  nent: 


System  Info  mat ion 


11)  Hardware  Characteristics: 


12)  Remarks  (indicate  Specific  Referent  Block  or  Subject): 


Form 

AMHL-0  89 

Aug  46  - 1 r  *  - 


13)  P«?rforaaace  Description 


I 

! 

[ 

L 

i 

t 

| 

I 

f 


Ik)  Performance  Characteristics 


15)  Personnel  Description 

16)  Tine  Information 

ftois 
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AMKL-0  89 

Au t  66 

i 


APPENDIX  V 


i 


DATA  ELEMENTS  (LUCID) 


j 


I 
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The  following  four  .lists  contain  the  elements  of  data  used  to  def 
C-5A,  SATURN,  and  INDEX  data  bases,  respectively.  Defir. '-ions  fo 
categories  are  contained  in  Appendix  II T  . 


ALCC  DATA  BASE 

ENTRY  NUMBER 
ENTRY  TYPE 
ENTRY  DATE 

SOURCE  IDENTIFICATION 

REVISION 

REVISION  DATE 

REMARKS 

MISSION  PHASE 

MISSION  SEGMENT 

FUN CT TON 

l/\oXV 

PERFORMANCE  DESCRIPTORS 
LOCATION 

HARDWARE  INFORMATION 
SPECIAL,  TOOLS  ^EQUIPMENT 
T.ASK  FREQUENCY 
HAZARDS 

SAFETY  PRECAUTIONS 

r>  ■*■**■»  ri-“  ~i\f  « 

*  wi«4  oiU’LrwIvJj  1  1  1  J.J 

TOTAL  TASK  TIME 

*  PERSONNEL  NAME 

*  Af’SC 

*  PERSONNEL  KUMLEP 

*  PERSONNEL  TIME 
Dir'ICULTY 
CRITICALITY 
TRAINING  REQUIREMENTS 


i  ne  the  AI. 
r  each  of  tf 


*  Each  of  these  elements  contains  multiple  values  that  share  a  correspondence 
with  each  other  across  the  elements,  e.g.,  the  first  values  for  PERSONNEL 
NAME  and  AFSC  are  directly  related,  an  .re  the  second  values,  and  so  forth 


fN"'1  v  7'vm- 
EJJTR'.  :  AT:-' 

SOURCE  IBENTIFI  OAT  j  <  in 

REVISION 

REVISION  DATE 

REMARKS 

MISSION  PHASE 

MISSION  SEGMENT 

FUNCTION 

TASK 

PERFORMANCE  DESCRIPTORS 
LOCATION 

HARDWARE  INFORMATION 
SPECIAL  TOOLS/EQUIPMENT 
TASK  FREQUENCY 
HAZARDS 

SAFETY  PRECAUTIONS 
PERFORMANCE  TYPE 
TOTAL  TASK  TIME 

*  PERSONNEL  NAME 

*  AFSC 

*  PERSONNEL  NUMBER 

*  PERSONNEL  TIME 

*  PERFORMANCE  DIFFICULTY 

*  PERFORMANCE  CRITICALITY 

*  TRAINING  REQUIREMENTS 

*  PERFORMANCE  FREQUENCY 

.£  nirwvm  - 

1_iV^  X  1  1’Llj  ll  i  VlUiDlljil  I 

*  EQUIPMENT  READABILITY 

»  EQUIPMENT  READABILITY 

*  EQUIPMENT  REAC%  ■'  BTLITY 

*  EQUIPMENT  MANIPULABILITY 

SPECIAL  SKILLS 

START  TIME 
STOP  TIME 


*  Each  of  these  elements  contains  mult iple  values 
with  each  other  across  the  elements,  e.y,.,  the 
NAME  and  AFSC  are  directly  related,  as  are  the 


that  share  a  < 
first,  values 
second  values 


■orrespondence 
I* or  PERC  NNEI 
,  and  so  forth. 
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•  Each  of  these  elec 
with  each  other  a< 
NAME  and  PEKCONNEI 
bo  forth. 


yy  u  .  'f'yyyy 
ne  ■  "  i  .  \  I  r. 

ENTI-r  DATE 

source  : dent: Ei :at: :n 

PET*  IS  ION 
REVISION  DATE 
REMARKS 
MISSION  PRASE 
MISSION  SEGMENT 
FUNCTION 
TASK 

P EP. FO RMAN CE  DESCRI PT 0 E S 

T  rtn  *  7  v 

j jULil  ,  j.  v_>  it 

HARDWARE  INFORMATION 
SPECIAL  TOO  IS  /EQUI PMENT 
TASK  FREQUENCY 
HAZARDS 

SAFETY  PRECAUTIONS 
PERFORMANCE  TVPE 
'COTA I,  TASK  TIrtE 
PERSONNEL  NAME 
PERSONNEL  CODE 
PERSONNEL  NUMBER 
CRITICALITY 
FUNCTION  PESCR T PTOPS 
FUNCTION  START  TIME 
FUNCTION  CHECKOUT  TIM? 
w t.-'.s  t?mv  pin'.i-.sn- 


aents  contains  suit  ipi 
■rose  the  elements,  ♦ 


va, ues 

■*  +  ’.’p 

s  •  *  v  . »  r~ 


tr-fi*  o,.ar  e 
f  i  r  s  *  v  a  1  •  i 


■'PE  are  directly  related,  as  are  the 


.  s'  •  ■:**  n  cat  eg  r  . f 

.  a  *  a  •  uo>-  is  ■  r  .  •  ••  i  i 


Definitions  for  the 


MI  FED  N  ERA  ID 
MI FF I  N  SEGMENT 
FUNCTION 
FYL-TEM  BRKAK.'./JT 

*  :  ERSONNEL  O  'L'E 

*  PERSONNEL  TYPE 
HARDWARE 

categories  are  the  same  as  those  defined  in  Appendix  III  , 


except  for  the  foi loving,  which  are  unique  to  INDEX: 


FYFDEU  contains  the  names  of  all  systems  for  woolen  data  bases  exist  in  the 
iata  tool. 


UPTHM  REilAKFL'D  con* ains  a  hierarchical  list  of  «!  1  mission  phase,  mission  seg¬ 
ment,  and  function  values.  It  is  used  t  provide  detailed  insight  into  the 
nature  of  a  nart  P'ular  s  voter,  iata  base. 


•KKF  '  NNED 


.a  ins  ^i  then  th 


or  NA.'A  designate  *■  personnel  codes 


Da  I.  of  these  elements  ••'.■>ntH!nt>  multiple  values  t  hat  share  a  correspondence 
with  each  arr  'ss  the  elements,  g.  ,  the  first  values  for  FrlRF'CNNEL 

t  DE  and  EKEF'NNED  DY- K  are  dire -fly  related,  as  are  the  second  values,  and 
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GUIDELINES  FOE  DATA  E 


General 


The  fundamental,  task  to  be  per f corned  is  to  extract  the  data  from  the  source 
materials  and  record  them  on  the  forms  provided.  The  ir.fcrr  .tier,  should  be 
recorded  exactly  as  it  appears  in  the  source  material.  Few  judgments  will 
be  necessary  on  your  part  to  complete  the  sixteen  items  on  the  form. 


Specific  Instructions 

Number  forms  sequentially  beginning  with  001 .  Place  the  number  in  space 
labeled  Index  Number. 


Block 

Block 

Block 

Block 

Elock 


Block 

Block 

Block 

Block 

Bloc* 


Block 

Block 


1  -  Will  always  be  "ALCC-AVE" 

2  -  Will  always  be  1./P5/66 

3  -  Wri te  Unclassified 

1+  -  Will  always  be  "Boeing'' 

3  -  Document  title  will  always  be  "Ai.CC  Operational 
Timeliness" 


6  -  Data  are  found  on  line  #30  of  the  Task  Informat 

7  -  Data  are  found  on  line  #11  of  US 

8  -  Data  are  found  on  line  #  1  of  TIS 

•>  -  Data  are  found  on  lines  #3  and  u  of  TIS 

10-  Extract  data  from  lines  #18  and  19  of  TIS 


Task  Ar.alys 
or.  Summary 


s  an  a 


a  Copy  each  different  coded  equipment  designator  from  the  time-line 
of  the  corresponding  task  time-line.  ; Examples  of  coced  designators 
are  circles  in  red  on  page  2  of  Section  2  (Time-lines). 

b.  Each  TIS  has  a  corresponding  TAWS  (Task  Analvs.  Work  Sheet). 

this  TAWS  is  found  on  the  page  fo1 lowing  the  TIS.  Extract  from 
paragraph  8  of  the  TAWS,  any  controls  or  equipment  tnat 
appears  with  a  check  (  y)  mark.  Supplemental  equipment  infor¬ 
mation  may  appear  in  paragraph  2  of  TAWS;  if  so.  include  this 
information . 


NOTE  :  Tools  are  not  equipment.  We  are  concerned  here  with 
equipment  components  and  subassemblies  We  are  not 
concerned  with  conditions  under  which  they  are  used. 

(See  Block  l6  remarks.)  Do  not  duplicate  equipments 
or  controls . 

11-  Will  always  be  blank 

11'-  Although  the  section  appears  eariy  in  the  form,  it  should  be  com¬ 
pleted  only  after  ail  otner  sections  have  been  completed,  ( Proceed 
to  Block  11.) 

■  .  Miscellaneous  comments  necessary  to  explain  any  of  the  other 
items . 
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r-re?i: :  iv 

t  h c  c  o r  r  *?  s  pon 
consists  c t . 


-  if  the  paragraph  *6  (Special  Handling)  of  TAWS  is 
considerable  -  recor i  from  paragraph  #  2  of  TAWS, 
ding  comment  regarding  vb  *  that  special  handling 


■  rd  any  comments  from  paragraph  #5  of  TAWS  regarding  Consequence 


d.  .Any  other  pertinent  information  which  you  feel  should  be  called 
to  our  attention  regarding  this  "task". 

:-ook  13-  Copy  each  step  in  sequence  from  Task  Time-line  of  corresponding  task. 
(Example  is  shewn  or.  page  2  of  Section  2,  Time-lines .  ) 


include  time  information.  It  is  recorded  in  another 


n-i.ee it  -u-  a 


See  line  of  TIS  for  location. 


:&e  _ :  r.e 


of  TIS  for  criticality /difficulty . 


t.  See  line  *2 2  -  2?  of  TIS  for  Training  Requirements. 

e.  See  paragraph  2  of  TAWS  for  special  tools  -  if  none,  write 
rone . 

f.  See  paragraph  T  of  TAWS  for  Safety  Precautions. 

NOIL' :  Per  this  item,  please  label  the  information  a  -  b  -  c_  -  etc. 
Block  15-  See  line  12  of  TIS. 

Block  it—  See  lines  le-lq-it  of  TIS.  Flease  give  time,  title,  i.e.,  elapsed 
time,  and  numerical  value. 

At  this  point.,  complete  Block  12,  a  -  d. 


r 


I 


I 
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GUIDELINES  FJR  DATA  EXTRACTION  C-5A 


Get  jral 

The  fundamental  task,  to  be  performed  is  to  extract  the  data  from  source  materials 
and  record  them  on  the  forms  provided.  The  information  recorded  should  be  recorded 
exactly  as  it  appears  in  the  source  materials.  Few  judgments  will  be  necessary 
cr.  your  part  to  complete  the  sixteen  items  on  the  form. 

Specific  Instructions 

Number  forms  sequentially:  Maintenance  beginning  with  ”01,  Operations  beginning 
with  U01.  Place  the  r.umoer  in  the  block  titled  "Index  Number". 

Block  1  -  Will  always  be  C-5A 

Block  2  -  Will  be  found  on  the  "Requirements  Allocation  Sheet"  (RAS)  or  the 
"Crew  Task  Analysis"  sheet  as  "Originator  &  Date".  If  a 
revision  has  been  made,  it  will  be  identified  on  the  "RAS"  or  the 
"Analysis" . 

Block  3  -  Will  always  be  Unclassified. 

Block  li  -  Will  always  he  Lockheed. 

Block  5  -  Maintenance  document  title  will  always  be  Requirements  Allocation 

Sheet  (RAS)  and  the  "Document  Number".  The  author  will  be  found  in 
the  lower  left  of  the  RAS  as  "Originator  and  Date". 

Operations  document  title  will  always  be  C-5A  Flight  Crew  Task 
Analysis . 

Block  6  -  For  maintenance  tasks,  copy  from  "Source  Document"  block. 

For  operations  taskc  use,  None . 

Block  T  -  For  maintenance,  use  Preventive  Maintenance  or  Maintenance  as 
indicated  by  source  documentation. 

For  operations,  use  Flight  Operations  -  Routine. 

Block  8  -  For  maintenance,  (F )  use  *itle  from  the  first  sheet  of  a  maintenance 
operation;  (T)  use  descriptor  title  of  operation  being  performed 
and  repeat  title  from  ( F ) ,  e.g,,(F)  Inspect  Aft  Pressure  Door  LH 
(T)  Remove  Aft  Pressure  Door  LH.  " 

For  operations,  ( F )  use  title  from  first  entry  of  "Analysis  Sheet" 
column  1*;  (T)  use  title  from  next  indenture  of  column  L,  e.g.,  (F) 

Start  Engines  and  Before  Take-off;  (T)  Check  Radios. 

Block  9  -  For  maintenance: 

Mission  -  transport  personnel/cargo 
Phase  -  ground  maintenance 
or 

phased  inspection 

Segment  -  enter  specific  operation  being  performed 
For  operations: 

Mission  -  transport  personnel/cargo 
Phase  -  preflight 
or 

flight 

Segment  -  enter  specific  operation  being  performed 


Block  10-  For  (?)  accumulate  all  hardware  items  used  in  subsequent  tasks. 


Fcr  (T)  and  maintenance  enter  information  found  in  columns  El  and 
E?  of  HAS. 

For  (T)  and  operations ,  enter  hardware  units  from  column  9  actually 
used  during  the  performance. 

Block  11-  For  maintenance,  enter  None . 

For  operations,  enter  code  found  for  eac'.  performer  under  the 
following  categories: 

Visible,  column  ]0 
Readable,  column  11 
Reachable,  column  12 
Manipulatable ,  column  13 

Block  12  -Although  the  section  appears  early  in  the  fc~n,  it  should  be 

completed  only  after  all  other  sections  have  been  completed.  Proceed 
to  Block  13.  Block  contents  will  consist  of: 

Miscellaneous  comments  necessary  to  explain  any  of  the  other 
items.  (Maintenance;  Column  C  of  the  RAS). 

Record  any  "Cautions"  or  "Notes". 

Record  any  pre-function  or  pre-task  conditions  that  must  be 
at  omplished  before  this  event  can  be  started. 


Fcr  maintenance ,  enter  any  data  from  column  G  of  the  RAS. 

Record  any  other  information  which  you  feel  should  be  called 
to  attention  regarding  the  task  or  function. 

Block  13-  If  (?)  copy  the  task  tides  that  are  included  under  this  function. 

If  (T)  copy  the  AFSC,  the  aetion(s)  performed  ara  the  time  required 
for  each  action. 


For  (Tl  maintenance  use  columns  F3,  FI,  and  F2. 
For  (T)  operations  enter  AFSC  as  follows: 


Pilot 
Copilot 
Navigator 
Flight  Engineer 
Loadmaster 


1055Z  -  column 
10l5Z  -  column  5 
1535Z  -  column  6 
1 585  -  column  7 

60570  -  column  8 


Copy  man/machine  action  from  appropriate  column  and  enter  time. 
Block  14-  Location  -  describe  location  where  performance  is  occurring. 

Use  column  9  on  "Analysis  sheet"  for  operations. 


For  operations: 

Enter  codes  as  indicated  in  the  particular  column  for  each 
performer  for  the  following  categories: 

Frequency,  column  lU 
™  fficulty ,  column  15 
criticality, column  lb 
T^ainir^  Requirements,  column  17 

NOTE:  If  more  than  one  value  is  entered  on  the  source  sheet,  for 
a  single  performer  in  any  of  the  above  categories,  always 
record  the  value  containing  the  highest  value  for  that  one 
task  only. 

For  maintenance : 

Enter  the  code  found  in  column  cf  the  RA3. 

Block  15-  Record  for  (T)  greatest  quantity  of  each  AFSC  required  in  columns 
5-  6,  7,  or  8  for  task  completion. 

Record  for  (F)  a  S’.immary  count  of  the  greatest  quantity  of  each 
AFSC  required  for  the  performance  of  any  one  task. 

Block  16-  For  maintenance  ( T_)  record  the  accumulated  time  required  for  each 
AFSC  type  to  perform  the  task,  then  adc  all  times  to  provide  a 
MAX  task  time. 

For  maintenance  (F)  record  the  MAX  task  time  for  the  tasks  within 
the  function. 


For 


For 

the 

At  this  point 


operations  (T)  record  as  follows: 

Time  limitations  -  column  25  and  2 6 
Start  time  -  columns  27  and  28 
Stop  time  -  columns  29  and  30 
Total  clock  time  -  columns  31  and  32 

Each  AFSC's  time  -  total  of  columns  31  and  32  for  each  AFSC 
Total  man  time  -  total  as  above  for  each  AFSC  times  the  number 
of  AFSC's  required 

operations  (F_)  record  the  total  clock  time  for  the  tasks  within 
function. 

complete  Block  12  (See  instructions  for  Block  12,  page  157  ). 
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GUIDELINES  FOR  DATA  EXTRACTION  (SATURN) 


General 

The  fundamental  task  to  be  performed  is  to  extract  the  data  from  source 
materials  and  record  them  on  the  forms  provided.  The  information  should  be 
recorded  exactly  as  it  appears  in  the  source  materials.  Few  judgments  will 
be  necessary  or  your  part  to  complete  the  sixteen  items  on  the  forms. 

Specific  Instructions 

Number  forms  sequentially  beginning  with  501.  Place  the  number  in  the 
space  labeled  Index  Number. 

block  1  -  Will  always  be  SV 

Block  Zr  ~  Get  date  from  bottom  of  each  first  analysis  sheet  of  documents 

D5-: 6001-910  and  D5-16001-523. 

No  revision  letter  for  the  -910  docume  .  Revision  letters  have 
been  included  in  the  -523  document  as  part  of  the  P.E.N/OPS 
Activity  No.  e.g,,  1523-12-C.  "C"  is  the  revision  lette". 

Will  always  be  Unclassified 
Will  always  be  Boeing 

Author  for  -901  will  be  found  at  bottom  of  first  analysis  sheet 
after  "Engineer". 

Author  for  -523  will  be  found  at  top  of  sheet  in  space 
"Prepared  By". 

Title  will  be  as  indicated 
Block  6  -  Will  always  be  none  when  using  -901  document. 

When  using  -523  document  references  will  be  found  at  bottom  of 
last  "Equipment  Maintenance"  sheet.. 

Block  7  -  Will  always  be  Maintenance 

Block  8  -  If  using  -901  record  (F)  the  name  found  in  "Event  Title"  and 

"EVent  No.". 

If  using  -523  record  (T)  then  name  in  "Nomenclature"  following 
"l"  in  column  U.  "Indenture"  on  first  sheet  of  Equipment 
M a i  o.t  e n a n ce  Sequence. 

Block  9  -  Will  always  be  as  follows: 

Mission  -  Assembly  Checkout,  Launch  Vehicle 
Phase  -  Vehicle  Systems  Analysis,  Pad,  Fueled. 

Segment  -  Maintenance  Analysis, 

Block  10-  For  (F)  accumulate  ail  special  tools  and  equipment  found  in 

columns  1,2  and  1  of  "Maintenance  Requirements  Analyses  Form". 

F  r  (T)  list  sequentially  all  equipment  found  in  Column  5 
'Nomenclature"  and  Column  6  Fug.  Model  Part  No."  of  "Equip¬ 
ment  Maintenance  Sequence"  and  also  the  equipment  found  in 
Column  5  of  "Maintenance  Requirements  Analysis  Form." 


Block  3  - 
31ock  h  - 
Block  5  - 
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Mock 

Block 


Block 


Block 


Block 


Block 


1.1  -  Will  always  be  none 

12  ~  Although  the  section  appears  early  in  the  form,  it  should  he 

completed  only  after  all  other  sections  have  been  completed. 

Block  contents  will  conSi^^  of- 

Miscellaneous  comments  necessary  to  explain  any  of  the  other 

items 

Record  ~ny  "Cautions"  or  "notes" 

Record  any  pre-function  or  pre-task  conditions  that  must  be 
accomplished  before  this  event  can  be  started. 

Record  any  other  information  which  you  feel  should  be  called 
to  attention  regarding  the  event . 

13  -  If  (F)  copy  sequence  from  "Sub  Event"  column  in  ' acumen £. 

If  , T)  copy  "equci.o*-  <.*  -^.--lons  enechea  xu  I  anc  of 

first  sheet  of  each  "Equipment  Maintenance  Sequence". 
lU  -Location  will  always  be  Kennedy  Space  Center,  Launch  Complex 
39  Mobile  launcher.  Launch  Control  Center. 

Criticality  will  be  the  greatest  criticality  recorded  for  the 
event  in  "perf  crit"  column  of  the  "Maintenance  Analysis 
Requirements  Analysis  Form" 

Criticality  index  is: 

A  -  Little  or  no  effect.  Would  not  affect  .he  mission  success. 

E  -  Could  result  in  some  degradation  oi  eq.  ipraent  but  would 
probably  not  affect  mission  success. 

C  -  Mission  success  would  be  compromised  to  an  unacceptable  degree. 

15- Eecwrd  for  (T) ,  man  type  and  greatest  single  quantity  required  for 

event  completion.  Record  as  found  in  Section  D  columns  2,  5,  ** 
of  "Maintenance  Requirements  Analysis  Form". 

Record  for  (F_)  a  composite  summary  of  personnel  required  for  each 
sub-event  or  task . 

16-  Record  time  in  minutes  but  MAX  Task  Time  is  to  be  recorded  in 
hours  and  minutes. 

For  (T),  record  time  required  to  compile  each  required  action. 

If  more  than  one  time  is  found  for  an  action,  -ecord  the  Largest 
as  (MAX). 

For  (?)  record  MAX  Task  Time  for  each  ^ask. 

At  this  point  complete  block  12. 
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APPENDIX  VII 
KEYPUNCHING  GUIDELINES 
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KEYPUNCHING  GUIDELINES 


Every  piece  of  input  consists  of  a  field  number,  one  or  more  spaces  a  value, 
and  one  or  more  spaces.  The  value  is  given  to  the  element  having  that  field 
number  in  the  data  base  description. 

1  (PREFLIGHT  OPERATIONS)  2  TAXI 

★ 

Values  for  string  elements  are  entered  by  repeating  the  element  field  nunber 

and  a  value 

9  THROTTLES  .  ,-oJDER  9  FLAPS 

Values  for  elements  in  a  string  set  are  entered  in  the  same  way  except  that 
the  order  in  which  they  are  entered  is  important.  The  first  value  for  an 
element  in  a  string  set  is  associated  with  the  first  value  tor  every  other  ele¬ 
ment  In  that  set,  and  so  or. .  If  a  value  for  one  element  in  a  string  set  exists, 
an  associated  value  f?**  ,  ;‘her  element  in  that  set  must  also  exist.  There¬ 

fore,  If  no  real  values  exist  for  certain  elements  In  a  string  set,  ’'dummy" 
values  must  be  inserted.  Values  for  a  string  set  may  be  entered  in  either  of 
the  following  ways: 

6  10552  7  (TROOP  CARRIER  PILOT)  6  10452  7  (TRANSPORT  PILOT) 

or 

6  10552  6  10452  7  (TROOP  CARRIER  PILOT)  7  (TRANSPORT  PILOT) 

One  or  more  blanks  may  separate  field  nimbers  and  values.  If  a  value  contains 
blanks  or  commas,  it  must  be  enclosed  in  parentheses.  If  3  value  contains 
embedded  oarentheses ,  left  and  right  parentheses  must  ^atch  and  the  entire 
value  must  be  enclosed  in  parentheses. 

5  (INSPECT  AnNUMICATOR  AND  WARNING  LIGHTS  (USE  TEST  SWITCH)  ) 

A  value  may  contain  not  more  that  256  characters  including  blanks. 

The  end  of  all  values  for  an  entry  is  indicated  by  the  entry  terminator  de¬ 
fined  in  the  data  base  description.  The  end  of  all  input  is  indicated  by  the 

word  TERM. 

Specified  keypunching  rules  were  also  followed: 

Columns  1  through  72  may  contain  data. 


•Related  string  elements  in  an  entry. 
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Column  1  of  each  card  is  treated  as  a  continuation  of  the  pre¬ 
vious  card,  allowing  a  field  number  or  value  to  extend  between 
cards . 


The  entry  terminator  may  not  be  split  between  cards. 

The  input  terminator,  TERM,  must  exist  on  a  card  by  itself. 

Data  values  may  bo  stoned  on  cards  in  two  wavs.  A  field  number  and  a  value 
may  exist  on  a  card  by  themselves  (figure  24)  or  a  field  number  and  a  value 
may  be  immediately  followed  by  another  field  number  and  value  (figure  24). 

The  first  method  provides  much  more  ease  in  the  desk  editing  of  the  data  and 
correction  of  errors  not  discovered  until  the  loading  of  the  data  base. 

The  second  method  provides  for  a  savings  of  storage  area  and,  in  the  event  of 
large  data  bases,  considerably  reduces  the  time  required  to  load  the  data  base. 
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APPENDIX  VIII 


C-5A  DATA  ELEMENTS 


I 


C-5A  DATA  ELnMSTCS 

i 

The  following  is  a  list  of  elements  in  the  C-5A  data  ba^e  as  restructured  for 

Trio. 


ENTRY  NUMBER 
ENTRY  TYFE 
MISSION  PHASE 
MISSION  SEGMENT 
TIME  SEGMENT 
TASK 

TASK  VERB 
TASK  STATEMENT 
TIME 

START  TIME 
STOF  TIME 
PERSONNEL 

AFP C  OFFICER 
AFSC  AIRMAN 
AIR  FORCE  SPECIALITY 
SKREDOUT 
POSITION  TITLE 
PERSONNEL  TIME 
PERSONNEL  NUMBER 
Dll FICULTY 
CRITICALITY 
TRAINING  REQUIREMENTS 
r ER FO RMAN C E  FPFQU E N C Y 
EQUIPMENT  VISISBIi.ITY 
EQUIPMENT  READABILITY 
EQi !  T  PMEN’”  REACHA  BI I .  IT  Y 
EQUIPMENT  MANTPULABI  L,ITY 
SPECIAL  SKILLS 

LOCATION 
EQUI PMENT 

EQUIPMENT'  ITEM 
SEE. TAP  T'O'LS  ’R  EQUIPMENT 

Si  FA’  ••  IViiLS  -R  ' '  I :  MET"  !  "EM 


hASA'O'S 
.  A- FT- 


'A ' 
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DEFINITION  OF  DATA  ELEMENTS  (TDMS) 
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DEFINITION  OF  DATA  ELEMENTS  (TD.MS) 

The  following  is  Hn  alphabetized  list  of  all  of  the  lata  elements  contained  in  the 
TT34S  (C-5A)  data  base.  The  list  contains  the  definitions  of  each  element. 

AFSC  AIRMAN  -  contains  the  Air  Force  Specialty  Cede  of  the  airmen  required 

to  perform  a  task. 

AFSC  OFFICER  -  contains  the  Air  Force  Specialty  Code  of  the  officers  required 
to  perforin  a  task. 

AIR  FORCE  SPECIALTY  -  contains  an  alphanumeric  designator  of  an  ability  or 
skill  not  restricted  to  a  single  utilization  or  career  field  for  each  individual 
involved  in  a  task. 

CRITICALITY  -  contains,  for  each  individual,  the  degree  of  criticality  associated 
with  the  performance  of  the  task. 

DIFFICULTY  -  contains,  for  each  individual,  the  degree  of  difficulty  associate! 
with  the  performance  of  the  task. 

ENTR"  DATE  -  contains  the  date  the  information  was  entered  In  the  data  base. 

ENTRY  NUMBER  -  contains  a  unique  numerical  identifier  assigned  to  each  entry 
as  it  is  entered  into  the  data  base. 

ENTRY  TYPE  -  designates  whether  the  data  base  entry  describes  a  time  segment 
as  originally  entereu  into  the  data  base,  or  whether  the  entry  has  been 
subsequently  updated.  If  update,  the  element  contains  a  short  description  of 
the  modification. 

EQUIPMENT  -  contains  no  data  values  but  is  merely  a  heading  for  a  repeating 
group  of  elements. 
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EQUIPMENT  ITEM  -  contains  the  names  or  designators  of  the  hardware  associated 
with  a  specific  task. 

EQUIPMENT'  MANIPULABILITY  -  indicates  how  well  an  individual  can  manipulate  the 
equipment  utilized  in  performance  of  a  task. 


EQUIPMENT  REACHABILITY  -  indi cates  how  veil  an  individual  can  reach  the 
equipment  utilized  in  performance  of  a  task. 

EQUIPMENT  READABILITY  -  indicates  how  veil  an  individual  can  read  a  display 
surface,  gauge,  =tc,.  utilized  in  performance  of  a  task. 

EQUIPMENT  VISIBILITY  -  indicates  how  veil  an  individual  can  see  an  item  of 
hardware  that  is  required  for  the  performance  of  a  task. 

HAZARDS  -  contains  information  regaiding  the  risk  associated  with  performance 
of  a  given  task. 

LOCATION  -  describes  the  physical  place  associated  with  the  performance  of  a 
task. 

MISSION  PHASE  -  contains  the  broadest  level  of  mission  profile  information 
associated  with  the  performance  of  task, 

MISSION  SEGMENT  -  contains  a  breakdown  of  the  mission  phase  in  which  a  task 
is  performed. 

PERFORMANCE  FREQUENCY  -  indicates  how  often  each  individual  involved  in  the 
task  performs  V.s  assigned  duties. 

PERSONNEL  -  contains  no  data  values  but  is  merely  a  heading  for  a  repeating 
group  of  data. 

PERSONNEL  NUMBER  -  contains  a  numeric  value  representing  the  number  of  each 
type  of  personnel  required  to  perform  a  task. 
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PERSONNEL  TIME  -  identifies  the  amount  of  time,  in  minutes,  spent  in  the 
performance  of  a  task  by  each  of  the  personnel  types  involved  in  the  task. 


POSITION  TITLE  -  contains  the  <  ’flcial  title,  e.g.,  pilot,  radio  repairman, 
of  each  type  of  personnel  involved  in  the  performance  of  a  task. 

REMAPJCS  -  contains  any  relevant  miscellaneous  comments  associated  with  a 
task, 

REVISION  -  contains  the  revision  code  associated  with  the  last  revision  of  the 

task. 

REVISION  DATE  -  contains  the  date  of  the  latest  revision. 

SAFETY  PRECAUTIONS  -  contains  statements  regarding  precautions  to  be  taken 
during  the  performance  of  a  task. 

SHREDOUT  -  contains  an  alphabetic  suffix  to  the  ‘'FSC  showing  qualifications 
in  specific  equipment  or  functions. 

SOURCE  -  contains  no  data  values  but  is  merely  a  heading  for  a  repe-i. Ing  group 
of  elements . 

SOURCE  IDENTIFICATION  -  contains  the  author,  L  ~ument  refernees,  originating 
organization,  security  classification  and  date  associated  with  the  analysis 

of  a  task. 

SPECIAL  SKILLS  -  contains  statt  -ent  identifying  the  visual,  verbal,  perceptual , 
motor.  Judgmental  capabilities  and  the  knowledge  of  theory  required  bv  individual: 
to  properly  perform  a  task. 

SPECIAL  TOOLS /EQUIPMENT  -  contains  no  data  values  but  is  merely  a  heading  for 
a  repeating  group  of  elements. 


SPECIAL  TOOLS  /EQL^PMENT  ITEM  -  contains  the  items  of  special  equipment  required 
to  perform  a  task. 

START  TIME  -  contains  the  time,  in  minutes,  at  which  a  task  begins.  Time  is 
calculated  chronologically  from  the  start  of  the  preflight  phase,  beginning 
at  zero  and  continuing  until  the  end  of  the  post- flight  phase. 

STOP  TIME  -  contains  the  stop  time,  in  minutes,  associated  with  the  performance  ; 

of  a  task.  , 

TASK  -  contains  nc  data  values  but  is  merely  a  heading  for  a  repeating 
group  of  elements. 

TASK  FREQUENCY  -  describes  how  often  a  task  is  performed. 

TASK  STATEMENT  -  describes  an  action,  performed  by  one  or  more  individuals  at 
specified  times,  directed  at  the  accomplishment  of  a  limited  goal. 

TASK  VERB  -  contains  the  verb  which  describes  the  action  or  process  of  the  task 
statement . 

TIME  -  contains  the  total  time,  in  minutes,  required  to  perform  a  task. 

TIME  SEGMENT  -  identifies  the  segment  of  time  during  which  a  related  group  of 
tasks  are  peri’  rmed. 

THAI NMN'1  REQUIREMENTS  -  identifies  those  specific  ‘ruining  requi r>*m#T,ts  necessary 
personnel  type  involved  in  the  performance  of  a  task . 
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build  and  match  program 


f 


i 


i 


PROGRAM  BUILD 


START  72  BUILD 
TABLE  INPUT  R  10  1  ; 
BEGIN 

ITEM  IN  H  8  0  0  N  ; 
ITEM  CH  H  1  C  0  M  ; 
END 

TABLE  OUTPUT  R  512  1  ; 
BEGIN 

ITEM  OUT  K  8  0  0  N  ; 

END 

TABLE  NAMES  R  9  1  ; 

BEGIN 


ITEM  NAME  K  8  0  0  N  ; 
BEGIN 


8h'(  NAME  Al«)  8k  (  NAME  #2*)  8H( NAME  t*=) 

8H(NAME  #6=)  #7=)  8H( NAME  *B~' 

END 
END 

TABLE  CODES  R  0  1  ; 

BEGIN 


ITEM  CODE  H  8  p  0  S 
BEGIN 

3H(COIF  #la)  8H{CCDE  MhuT/TE  *<=1 

8K\'Tie:  *('*}  ^hs'ooie  *"=}  *wii cciv 
END 


ENT 


ITEM  T1  I  k?  r  ■ 

I  TEN!  TO  I  IS  . 

» 

ITEM  PPCFI !  E  H  »• 

ITEM  NT  h  8  p  PHv’SNI 

ITEM  TELTVI  f  *  H(?ii.TVF '  ; 

ITEM  YES  {•’  i  r  ihjy!  . 

ITEN*’  NO  H  i  r  IKiN)  ; 

ITEM  BLANK  !<  r  j-  •••-  : 


8h’  l  NAMF  = 
8H(NAME  .*■■-= 
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PROC  IDTTY 
BEG 1 N 


IF  CH  NQ  YES  ; 

GOTO  A30  ; 

PI.10T  12Il(ENTER  SYSTEM'  ; 

RUTTY  ; 

XFKR(O)  ; 

Ai»0.  PRINT  1UH (LIMIT  MISSION?  )  ; 
RDTTY  ; 

IF  CH  EQ  NO  ; 

GOTO  A50  ; 

IF  CH  NQ  YES  ; 

GOTO  AUC  ; 

PRINT  11H( ENTER  PHASE  ; 

RDTTY  ; 

XFEF(IO)  ; 

PRINT  1 :JH ( ENTER  SEGMENT)  ; 

RDTTY  ; 

XFER ( 20 )  ; 

IF  OUT [20]  EQ  3H ( NONt  )  ; 

OUT  [20]  EQ  BLANK  ; 

A50.  PRINT  1?H(  LIMIT  FUNCTION" '  ; 
RDTTY  ; 

IF  CH  EQ  NO  ; 

GOTO  AbO  ; 

IF  CH  NQ  YES  ; 

GOTO  A 0  . 

’’RINT  1  !*H ( ENTER  FUNCTUS'  , 

RDTTY 

3CFER  (  30 )  ; 

a6o.  print  : shc limit  hartwa:-:-:-:  :  ; 

RDTTY  ; 

IF  CH  EQ  SC  ; 

GOTO  ATO  ; 

IF  CH  NQ  YES  , 

■GOTO  A 60  , 

FOR  A  -  0,1,3  ; 

BEGIN 
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RITE ( TELTYP , NAMES+ A , i )  ; 
RDTT'Y  ; 

XFEH ( 40+IC*A  )  ; 

I'  OUT [ 40+I0#A ]  eq  nd  ; 

GOTO  A70  ; 

END 

OUT [ 1 30 ]  =  ND  ; 

A70.  PRINT  1 6 H ( LIML?  FERSONNEL? ) 
IF  CH  EQ  NO  ; 

GOTO  A80  ; 

IF  CH  NQ  YES  ; 

GOTO  A TO  ; 

FOR  A  =  0,1,8  ; 

BEGIN 


X  FER ( 1 4  0 ♦ 1 0  »A )  ; 


PROGRAM  MATCH 


START  72  MATCH 

TABLE  DATA  F  512  1  ; 
BEGIN 

ITEM  D1  h  8  0  0  N  ; 
END 

TABLE  PRCFL  R  500  1  ; 
BEGIN 

ITEM  ,“1  H  8  0  0  N  ; 
END 

TABLE  INPUT  fill; 
BEGIN 

ITEM  IN  H  6  0  0  M  ; 
END 

TABLE  OUTPUT  R  18  1  ; 
BEGIN 

ITEM  OUT  H  8  0  C  N  ; 
BEGIN 


SH( SYSTEM  -) 

SHI  ) 

8H(  TASK  - 

)  8H( 

8H(  ) 

8H( 

8h( 

)  3H( 

8H(  ) 

8h( entry  #  ) 

8h( 

)  3H(  mvPE 

3H(  ) 

3H(  ) 

8h( 

)  3h( 

8H (  )  SH(  ) 

END 

END- 

TABLE  NXTFLD  R  LOO  1  ; 

BEGIN 

ITEM  FLD  H  8  ;•  N  ; 

END 

ITEM  MTCH  H  1  ; 

ITEM  T1  I  L8  U  ; 

ITEM  SYSTEM  H  6  ; 

ITEM  DCOL  I  ^8  U  ; 

ITEM  DROW  I  18  U  ; 


) 

\ 

/ 
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ITEM  CTSWRP  I  1*8  U  ; 

ITEM  PROW  I  1*8  U  ; 

ITEM  NUENT  H  1  ; 

ITEM  NOENT  H  1  ; 

ITEM  SCTRNO  I  1*8  U  ; 

ITEM  CHAR  I  1*8  U  ; 

ITEM  FRSTM  I  1*8  U  ; 

ITEM  FLAG  H  1  ; 

ITEM  YES  H  1  P  1H(Y)  ; 

ITEM  NO  H  1  P  l.H  ( N )  ; 

ITEM  WRDS1  I  1*8  U  ; 

ITEM  WPDS2  I  1*8  U  ; 

ITEM  NUM  H  2  ; 

ITEM  BLANK  H  8  P  8H(  )  ; 

PROG  CHKIT  ; 

BEGIN 

IF  BYTE(7 ,1  ,D1 ,  [DROv]  ,S)  EQ  2*0{T6,»  ; 

BEGIN 

REED .  RDX1  ( SYSTM , SCTRNO, DATA ,51?=T1 ) 
SCTRNO  =  SCTRNO  +  i  ; 

DROW  *  0  ; 

DCOL  =  0  ; 

Efti-i 

IF  BYTE ( 7 , 1 , D1 [ DROW ] , 8 )  EQ  20(75)  ; 

GOTO  REED  ; 

IF  BYTE (7,1 , D 1 [ DROW ] , 8 )  EQ  20(77)  , 

BEGIN 

PRINT  1H(  )  ; 

PRINT  13H( ERROR  IN  DATA)  ; 

STOP  ; 

END 

END 

PROC  MOV IT  ; 

ITEM  PAREN  I  '*8  U  ; 

BEGIN 
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POR  A  =  0,1,8  ; 

BEGIN 

FLDfAj  =  BLANK  ; 

END 

CHAR  a  0  ; 

FOE  A  -  0,1,36  ; 

BEGIN 

for  b  «  0,1,7  ; 

BEGIN 

TST,  IF  BYTE ( BCOL , 1 , Di [ GROW ] , 8 )  EQ  1H(  ) 
BEGIN 

IF  CHAR  EQ  C  ; 

BEGIN 
HIT  ; 

GOTO  TST  ; 

END 

IF  PARETO  EQ  0  ; 

RETURN  ; 

GOTO  MOVE  ; 

END 

IF  BYTE ( DCOL ,  1  ,D1  f  .CROW ] , 8 )  EQ  1H(  ( )  • 

BEGIN 

IF  PAREN  EQ  0  ; 

EEGIN 

PAREN  =  1  ; 

HIT  ; 

GOTO  TST  ; 

END 

PAREN  *  PAREN  +  1  ; 

GOTO  MOVE  ; 

END 

IF  BYTE(DC0L,1,[DR0W],8)  EQ  IH( )); 

BEGIN 

IF  PAREN  EQ  1  ; 

BEGIN 
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PAREN  =  0  ; 

HIT  ; 

RETURN  ; 

END 

PAREN  =  PAREN  -  1  ; 

GOTO  MOVE  ; 

END 

MOVE .  SBYT(B,1  ,FLI)f A]  ,8, BYTE (DCOL ,1  ,D1 ,  [DROW]  ,8)=FLD[A] ) 
CHAR  =  CHAR  +  i  ; 

KIT  ; 

END 

END 

END 

PRCC  HIT  ; 

BEGIN 

DCOL  =  DCOL  +  i  ; 

IF  DCOL  EQ  8  ; 

BEGIN 
DCOL  =  0; 

DROW  -  -'ROW  +  I  ; 

CONVRD  s  CONW.RD  +  1  ; 

IF  CONWRD  EQ  10  ; 

BEGIN 

IF  BYTE (7 , .1 , D 1  [ DROW ] , 8 }  EQ  20(32); 

BEGIN 

DROW  -  DROW  +  ]  ; 

RETURN  ; 

END 

CHKIT; 

END 

END 

END 

PROC  MTCHIT  ; 

BEGIN 

YY.  FOR  A  =  0,1,8  ; 

BEGIN 
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IF  PI [ PROW+A ]  NQ  FLD[A]  ; 

BEGIN 

ZZ.  MTCH  =  NO  ; 

RETURN  ; 

END 

MTCH  -  YES  ; 

END 

END 

PROC  NOVRDS  ; 

BEGIN 

FOR  A  «  0,1,8  ; 

BEGIN 

IF  OlFT  [  A  ]  EQ  BLANK  ; 

BEGIN 

OOT[A]  =  160(3277606060606060) 

WRDS1  «  A  +  1  ; 

GOTO  QQ  ; 

END 

END 

SBYT»7,l,OUT[8] ,8,20(32)*0UT[8] )  ; 

QQ.  FOR  B  «  9,1,17  ; 

BEGIN 

IF  OUT[B]  EQ  BLANK  ; 

BEGIN 

oirr[B]  -  160 (3277606060606060) 

WRDS2  ■  B  -  8  ; 

RETURN  ; 

END 

END 

SBrP(7,l,0UT[l7],8,20(32)»0UT[.  ;])  ; 
WRDS2  -  9  i 
END 

PROC  FLDNUM  ; 

BEGIN 

NUENT  -  1H(  )  ; 

NOENT  •  1H(  )  ; 
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FIND.  IF  BYTE(DCQL ,1 ,D1 , [DROW ] ,8)  EQ  1H(  ); 

BEGIN 
HIT  ; 

GOTO  FIND  ; 

END 

IF  BYTE(DC0L,3,D1[J?R0W],8)  EQ  3H(END)  ; 

BEGIN 

NUENT  =  YES  ; 

HIT  ; 

HIT  ; 

HIT  ; 

GOTO  FIND 
END 

IF  BYTE (DCOL,l*,Dl[ DROW]  ,8)  EQ  1*H(TERM)  ; 

BEGIN 

NOENT  =  YES  ; 

RETURN  ; 

END 

NUM  =  B'YTE(DC0L,2,Dl[DR0W]  ,8)  ; 

HIT  ; 

HIT  ; 

MOVIT  ; 

IF  NUM  EQ  2H(  1  )  ; 

BEGIN 

FOR  W  =  0,1,8  ; 

BEGIN 

IF  BYTE(W,l,FLDf0],8)  EQ  1H(  )  ; 

BEGIN 

SBYT( W, 1 ,FLD[0 ] ,8 ,1H( i )=FLD[ 0 ] } ; 

GOTO  WW  ; 

END 

END 

ww.  sbyt(o,:.,out[io],8,byte(o,i*,fld[o],8)»out[io])  ; 

END 

IF  NUM  EQ  2H( 2  )  ; 

BEGIN 
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FOR  A  *  0,1,5  ; 

0UT[l2+A]  =  FLD[A]  ; 

END 

IF  NUM  EQ  2h(ll)  ; 

BEGIN 

FOR  A  »  0,1,5  ; 

OUT[3+A]  =  FLD[A]  ; 

END 

IF  NUM  EQ  2H(1  )  OR  NUM  EQ  2H(8  )  OR  NUM  EQ  2H(9  )  OR  NUM  EQ  2H(lO)  OR 
NUM  EQ  2H(l4)  OR  NUM  EQ  2H(2l)  ; 

RETURN  ; 

GOTO  FIND  ; 

END 

AA.  FOR  A  =  0,1,512  ; 

D1[A]  =  BLANK  ; 

FOR  B  =  0,1,500  ; 

P1[B]  a  BLANK  ; 

CONWRD  =  1  ; 

FRSTM  =  1  ; 

FLAG  =  1H(  )  ; 

PRINT  1H(  )  ; 

PRINl  18H( ENTER  PROFILE  NAME)  ; 

READ (6H(TELTYP), INPUT, l)  ; 

FOR  B  0,  ’  ,7  ; 

BEGIN 

IF  BYTE( B,1 , IN ,8)  eq  20(32)  ; 

S3YT(B,I ,IN,8,1H(  )-IN)  ; 

END 

IF  BYTE(0,i*,IN,8)  EQ  LH(NONE)  ; 

BEGIN 

PRINT  1H(  )  ; 

PRINT  15H(MATCH  CONCLUDED)  ; 

STOP  ; 

END 
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PRINT  1H(  )  ; 

PRINT  7H{ STANDBY)  ; 

BB.  FIL3(IN,11,ih(c),o,IN,0,0,500=TI,T1,T1) 

RDX1 ( IN , 0 ,PROFL , 500=T1 )  ; 

IP  Pi  EQ  BLANK  ; 

SYSTM  =  6H(SYMALC)  ; 

IP  BYTE(0,i*,Pl,8)  EQ  kH(ALCC)  ; 

BEGIN 


SYSTM  =  6H(SYMALC )  ; 

OUT[l.J  =.  8H(  AJjCC  ;  )  ; 

END 

IP  BYT£(0,1»,P1,8)  EQ  bH(C-5A)  ; 
BEGIN 

SYSTM  =  6H(SYMC5A)  ; 

out [ i J  =  8h(  c-;a,  )  ; 

END 

IF  BYTE(Q,6,P1,8)  EQ  6H ( SATURN ;  ; 
BEGIN 

SYSTM  =  bH(SYMSAT)  ; 

OUTf 1 J  =  8H(  SATURN,)  ; 


LNV 


m-  ,SYS7Mfo,0,10000*Tl,Tl,n 


BB1 . 

FIL3(SY 

RDXI 

■  i SVSTM,C , 

SCTR 

;N0  =  i  , 

DCOL 

=  O  ; 

DROW 

-  0  ; 

BBS . 

FLDNUM  ; 

BB 

PROW  =  j 

MTCH 

-  YES  ; 

IF  Nt. 

'ENT  EQ  YE 

GOTO 

END IT  : 

DC. 

GOTO 

ip  PiUoj 

K  K 

BD. 

r,z.  , 

IF  NUM  NQ 

BEG 

IN 
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FLDNUM  ; 

IF  NUENT  EQ  YES  ; 
GOTO  BB3  ; 

GOTO  DD  ; 

END 

MTCHIT  ; 

IF  MTCH  EQ  NO  ; 

GOTO  XX  ; 

FLDNUM  ; 

IF  NUENT  EQ  YES  ; 

GO'T'O  B33  ; 

EE.  PROW  *  20  ; 

IF  Pl[ 20 ]  EQ  BLANK  ; 
GOTO  GG  ; 

17.  IF  NUM  NQ  2H(9  ) 
BEGIN 
FLDNUM  ; 

IF  NUENT  EQ  YES  ; 
GOTO  BB3  ; 

GOTO  FF  ; 

END 

MTCHIT  ; 

IF  MTCH  EQ  NO  ; 

GOTO  XX  ; 

FLDNUM  ; 

IF  NUENT  EQ  YES  ; 

GOTO  BB3  ; 

GG.  PHOW  *  30  ; 

IF  Pit  30 ]  -  BLANK  ; 
GOTO  II  ; 

RK.  IF  NUM  NQ  2H(iO) 
BEGIN 
FLDNUM  i 

IF  NUENT  EQ  YES  ; 
GOTO  BB3  ; 

GOTO  HH  ; 


END 

MTCHIT  ; 

IF  MT'JH  EQ  NO  ; 

GOTO  XX  ; 

FED NUM  ; 

IF  NUENT  EQ  YES  , 

GOTO  BB3  ; 

II.  IF  Pl[ UO j  EQ  BLANK  ; 
‘GOTO  LL  ; 

JJ.  IF  NUM  NQ  2H(1U)  ; 
BEGIN 
FLDNUM  ; 

IF  NUENT  EQ  YES  ; 

GOTO  3B3  ; 

GOTO  ivK  ; 

END 

FK.  FOR  H  =  UO, 10,130  ; 
BEGIN 

IF  FliH]  EQ  8H ( END 
BEGIN 
FLDNUM  , 

IF  NUENT  EQ  YES  ; 
GOTO  BUj  ; 

IF  NUM  NQ  LHilQ)  ; 
GOTO  XX  , 

-UU  KK  ; 

END 

PROW  *  H  ; 

*7' -’HIT  , 

IE  M"\'w  f  vv<:  . 

‘  ‘  *  "  *  ^  * 


END 

:F  1  i  E^  BLANK  , 

GO IV  XX  , 

MM.  IF  NUM  »Q  NH i N1  ; 
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BEGIN 
FLDNUM  ; 

IF  NUENT  EQ  YES  ; 

GOTO  BB3  ; 

GOTO  MM  ; 

END 

NN.  FOR  P  =  11*0,10,230  , 

BEGIN 

IF  P1[P]  EQ  oH(END  )  ; 

BEGIN 
FLDNUM  ; 

IF  NUENT  EQ  YES  ; 

GOTO  BB3  ; 

IF  NUM  NQ  2H ( 21 )  , 

GOTO  XX  ; 

GOTO  NN  ; 

END 

PROW  =  P  ; 

MTCHIT  ; 

IF  MTCH  EQ  YES  ; 

GOTO  XX  ; 

END 

XX.  IF  NUENT  EQ  YES  , 

BEGIN 
FLDNUM  ; 

GOTO  Xa  ; 

END 

IF  MTCH  EQ  YES  , 

BEGIN 
NOWRDS  ; 

PRINT  IH(  ;  , 

R I TE  ( 6  H  ( T  ELTY  F  } ,  01TPU7 ,  WP.  PS  I :  ; 
SITE(t-H(TEI.TYF)  .OUTPUT*?  .WRIST  )  . 
FUG  *  YES  , 

ENT 
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EQ  BLANK  ; 


GOTO  BB3  ; 
ENDIT.  IF  FI 


BEGIN 

IF  FRSTM  FQ  1  ; 

BEGIN 

SYSTM  =  6H(SYMC5A)  ; 

OUT [ 1 ]  =  8H(  C-5A  ;  )  , 
FRSTM  =  FRSTM  +  I  ; 

GOTO  BB1  ; 

IF  FRSTM  EQ  2  ; 

BEGIN 

SYSTM  =  bH(SYMSAT)  , 

OUT r  ;  =  8H(  SATURN ; )  ; 
FRSTM  =  FRSTM  +  1  ; 

GOTO  3B1  ; 

END 


ENT 
IF  FLAG 


Hu 


t>  J  i  » 

PRINT  IB;  '  ; 
PRINT  1  H  i.  MAT  ■ 
jO  *V  hA  , 

rlNL 

PRINT  iiiv  )  ; 
PRINT  3h(  NO  MAT.T 


vOnc:  ur.Ei; ) 


KM  AA  ; 
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FACETED  CLASSIFICATION  ELEMENT  NAMES  AND  DEFINITIONS 


The  primary  sources  for  the  definition  of  these  terms  were:  the  Handbook  of 
Instructions  for  Aerospace  Personnel  Subsystem  Design  AFSCM  80-3;  Policies  , 
Procedures  and  Criteria,  AFM  26-1;  Military  Personnel  Classification  Policy 
Manual,  AFM  35--U  Officer  Classification  Manual  36-1;  Airman  Classification 
Manual,  AFM  39-1 ,  and  an  examination  of  time-lines  of  aerospace  systems. 

The  terms  in  the  list  are  ordered  to  adher~  to  the  classification  structure 
since  this  is  more  meaningful  than  an  alphabetical  arrangement. 

1.  SYSTEM  -  A  composite  of  equipment,  skills,  and  techniques  capable  of 
performing  and/or  supporting  an  operational  (or  nonoperational )  rol**  •  An 
operational  role  refers  to  a  system  program  wherein  the  system  is  intended 
for  use  by  an  operational  command.  A  nonoperational  role  refers  to  a  system 
program  wherein  the  system/equipment  is  intended  for  use  for  other  than 
operational  employment  by  using  commands.  Extended  test  support  equipment 
are  often  nonoperational  in  this  sense.  A  complete  system  includes  related 
facilities,  equipment,  material  services  and  personnel  required  for  it.' 
operation  to  the  degree  that  it  can  be  considered  a  self-sufficient,  unit 

in  its  Intended  operational  (or  nonoperational)  and/or  support  environment. 

2.  PHASE  -  A  major  division  of  the  operational  or  support  role  of  a  system. 

For  example,  in  an  aerospace  system,  ground  maintenance- and  flight  opera¬ 
tions  constitute  phases. 

3.  SEGMENT  -  A  major  division  of  phase.  For  example  in  an  aerospace  system, 
flight  line  maintenance  and  bench  maintenance  would  constitute  subdivisions 
of  ground  maintenance;  cruise,  and  approach  and  landing  are  subdivisions 

of  flight  operations. 

1*.  TASK  -  A  related  group  of  subtasks,  performed  by  one  or  more  individuals 
at  specified  or  unspecified  times  during  the  operation  and  maintenance  of 
a  system,  that  are  directed  to  the  accomplishment  of  limited  goals.  Tasks 
are  most  often  performed  at  specified  times,  although  they  may  be  performed 
continuously  cr  on  an  as-required  basis,  throughout  the  system's  cycle.  A 
task  may  consist  of  a  single  operation  when  there  are  no  subtask3  that  must 


be  performed  before  the  task  can  be  completed.  For  example,  tuning  a 
radio  transmitter  to  a  desired  frequency  is  a  task  consisting  of  a  related 
group  of  subtasks.  Rotating  a  switch  on  a  radio  transmitter  to  change  from 
one  transmission  frequency  to  another  qualifies  as  a  task  since 
the  single  operation  completes  the  limited  goal.  An  operation  of  the 
latter  type  would  be  a  subtask  if  it  were  in  a  related  series  of  actions 
required  to  tune  the  transmitter. 

5.  TASK  TYPE  -  An  independent  subtask  (a  task  that  involves  a  single 
individual)  and  coordinated  task  (a  task  that  involves  more  than  one 
individual  in  its  performance ) 

6.  TASK  SEQUENTIAL  ORDER  -  The  order  of  task  start  uime  calculated  from  the 
beginning  of  a  segment.  The  sequential  order  is  designated  by  a  number. 

For  example,  7  would  indicate  that  this  task  was  the  seventh  task  to 
start  at  a  different  sequentially  ordered  time  since  the  beginning  of 
the  segment.  If  more  than  one  task  starts  at  the  same  time,  a  decimal 
point  is  placed  after  the  sequential  order  number.  For  example,  7.1  and 
7.2  indicate  ohat  two  tasks  start  at  sequential  order  7. 

7.  TASK  SEQUENTIAL  DEPENDENCIES  -  Tasks  that  are  sequentially  related  to  each 
other.  This  type  of  relationship  stipulates  that  the  performance  of 

each  subsequent  task  in  the  sequence  after  the  first  task,  is  dependent 
upon  the  accomplishment  of  the  previous  task.  Withir  a  dependent  sequence 
of  tasks,  there  may  be  secondary  dependent  sequences,  but  these  remain 
as  parts  of  ..he  overall  dependent  sequence.  For  example,  if  two  specialists 
ire  to  complete  separate  tasks  in  a  dependent  .--squence  it  would  be  possible 
for  one  specialist  to  complete  his  task  without  the  other  doing  likewise. 

But  the  failure  to  complete  both  of  the  tasks  would,  of  course,  result 

in  a  failure  to  complete  the  task  sequence  and  to  satisfactorily  accomplish 

its  objective. 

8.  TASK  TIME  -  Task  time  is  classified  as  Specific  if  the  task  both  occurs 
at  a  fixed  point  in  the  system's  cycle  and  has  a  known  time  duration. 
Specific  time  can  be  expressed  by  numerical  values  that  indicate  its 
time  interval  or  duration  length.  If  a  task  is  only  performed  when  a 
special  need  arises,  it  is  expressed  by  the  term  As  Required.  For  example. 
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emergency  procedures  are  periormed  on  an  as-required  basis.  If  a  task 
is  performed  continually  or  periodically  throughout  a  segment,  then 
task  time  is  expressed  by  the  terir  Continuous .  A  continuous  task  is  often 
performed  while  a  series  of  tasks  with  specific  times  is  also  performed. 
Generally, the  continuous  tasks  are  performed  without  interfering  with  the 
performance  of  specific  tasks.  Examples  of  continuous  tasks  are: 
monitor  intercom;  maintain  directional  control  of  the  aircraft. 

9.  TOTAL  TASK  TIME  -  A  numerical  value  that  expresses  the  amount  of  time 
required  to  perform  a  task.  Total  task  time  is  expressed  by  minutes  and 
hundredths  of  minutes. 

10.  TASK  INTERVAL  TIME  -  Two  numerical  values  that  express  the  interval  in 
which  the  task  is  to  be  performed.  The  two  numerical  values  represent  the 
start  and  stop  times  associated  with  the  task.  Task  interval  time  is 
expressed  in  terms  of  minutes  and  hundredths  of  minutes. 

11.  SUBTASK  (repeating  group)  -  One  of  a  series  of  related  actions,  performed 
by  one  or  more  individuals,  required  tc  accomplish  the  limited  goal  of 

a  task.  For  example,  the  individual  steps  required  to  tune  a  transmitter 
are  the  subtasks.  If  a  task  g>~al  requires  a  single  action,  the  task  and 
subtask  are  regarded  as  one  and  the  same  (see  item  4). 

12.  SUBTASK  TYPE  -  An  independent  subtask  (a  subtask  that  involves  a  single 
individual)  or  a  coordinated  subtask  (a  subtask  that  involves  more  than 
one  individual  in  its  performance) 

13.  ACTION  VERB  -  An  expression  of  the  act  or  process  of  producing  an  effect 
or  performing  a  function.  The  action  verbs  must  always  be  in  the  present 
tense  and  in  the  indicative  mood. 

14.  ACTION  DESCRIPTION  -  A  short  descriptive  statement,  beginning  with  the 
action  verb,  that  describes  the  action  that  is  taking  place  in  the 
subtask.  For  example,  adjust  (action  verb)  trim  or  aircraft  for  level 
flight. 
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15.  SUBTASK  SEQUENTIAL  ORDER  -  The  order  of  subt&sk  start  time  calculated 
from  the  initiation  of  a  task.  The  sequential  order  is  designated  by  a 
number.  For  example,  5  would  indicate  that  a  subtask  was  the  fifth 
subtask  in  sequential  order  to  start  at  a  different  time  since  the  start 
of  the  task.  If  more  than  one  subtask  starts  at  the  same  time,  a  decimal 
point  is  placed  after  the  sequential  order  number.  For  example,  5.1  and 
5.2  indicate  two  subtasks  starting  at  sequential,  order  5- 

16.  SUBTASK  SEQUENTIAL  DEPENDENCIES  -  Subtasks  that  are  sequentially  related 
to  each  other.  This  type  of  relationship  stipulates  that  the  performance 
of  each  subsequent  subtask  in  the  sequence  after  the  first  subtask  is 
dependent  upon  the  accomplishment  of  the  previous  task.  Within  a 
dependent  sequence  of  subtasks,  there  may  be  secondary  dependent  sequences, 
but  these  remain  as  parts  of  the  overall  dependent  sequence.  For  example, 
if  two  sp  cialists  are  to  complete  separate  subtasks  in  the  same  task,  it 
is  possible  for  one  specialist  to  complete  his  assignment  without  the 
others  doing  so.  The  failure  to  complete  all  of  the  subtask3  would,  of 
course,  result  in  a  failure  to  complete  the  task  and  to  satisfactorily 
accomplish  its  objective. 

17.  TOTAL  SUBTASK  TIME  -  A  numerical  value  that  expresses  the  amount  of  time 
required  to  perform  a  subtask.  Total  subtask  time  is  expressed  by 
minutes  and  hundredths  of  minutes. 

18.  SUBTASK  INTERVAL  TIME  -  Two  numerical  values  that  express  the.  interval 
in  which  the  subtask  is  to  be  performed.  The  two  numerical  values 
represent  the  start  and  stop  times  associated  with  the  subtask.  Subtask 
interval  time  is  expressed  by  minutes  and  hundredths  of  minutes. 

19.  AIR  FORCE  SPECIALITY  CODE  (AFSC)  -  A  code  consisting  of  a  combination  of 
digits,  or  digits  and  letters,  used  to  identify  a  given  Air  Force 
specialty.  For  example,  1538  signifies  Navigator,  an  officer  AFSC, and 
60570  signifies  Transportation  Supervisor,  an  airman  AFSC.  A  letter  prefix 
and  suffix  may  be  assigned  to  both  officer  and  airman  AFSC's. 

20.  UTILIZATION  FIELD  -  The  first  two  digits  of  the  officer  AFSC.  It  signifies 
a  grouping  of  Air  Force  officer  specialties  closely  related  on  the  basis 

of  required  skills  and  knowledge.  For  example,  the  Pilot  Utilization  Field 


(10  through  14)  encompasses  the  function  of  program  formulation,  policy 
planning,  inspection,  training  and  direction  and  performance  of  combat 
and  operations  activities  as  they  relate  to  aircraft.  In  certain  cases, 
the  skills  and  knowledge  required  for  a  given  utilization  field  are  of 
such  a  specialized  nature  that  they  are  not  directly  related  to  those 
required  by  another.  When  this  condition  occurs,  the  specialty  and 
utilization  field  are  the  same. 

21.  UTILIZATION  FIELD  DESCRIPTION  -  A  statement  of  what  the  utilization 

field  number  refers  to.  For  example,  10_  through  li_  identifies  the  pilot 
utilization  field. 

22.  CAREER  AREA  -  The  third  digit  of  the  officer  AFSC,  in  combination  with 
the  first  two  digits.  It  signifies  a  grouping  of  officer  utilization 
fields  that  are  broadly  related  on  the  basis  of  required  skills  and 
knowledge.  For  example,  1U3  the  Air  Operations  Career  Area,  encompasses 
those  utilization  fields  directly  required  to  employ  weapon  and 
supporting  systems  to  accomplish  the  primary  operational  mission  of  the 
Air  Force.  Included  in  the  area  are  the  Pilot,  Navigator-Observer  , 
Aircraft  Control,  Weapons  Director,  Missile  Operations,  and  Safety 
Utilization  Fields. 

23.  CAREER  AREA  DESCRIPTION-  A  statement  of  what  the  Career  Area  number  refers 
to.  For  example,  1^3  identifies  Air  Operations  Career  Area. 

2I4.  LEVEL  OF  QUALIFICATION  -  The  fourth  digit  of  the  officer  AFSC.  It 

indicates  the  level  of  qualification  within  a  career  area.  The  level 
signifies  potential,  partial  or  full  qualification. 

25.  LEVEL  OF  QUALIFICATION  DESCRIPTION  -  A  statement  of  what  the  Level  of 
Qualification  number  refers  to.  For  example,  1!*3_5  identifies  fully 

qualified. 

26.  CAREER  FIELD  -  The  first  two  digits  of  the  airman  AFSC.  It  signifies  a 
grouping  of  related  Air  Force  specialties  :nvolving  basically'  similar 
knowledge  and  skill.  For  example,  the  airman  Transportation  Career 


-176- 


Field,  6(1,  encompasses  the  functions  involved  in  the  movement  of 
personnel  and  materials  by  military  and  commercial 
transporation  facilities. 

27.  CAREER  FIELD  DESCRIPTION  -  A  statement  of  what  the  career  field  number 
refers  to.  For  example,  60  identifies  the  Transportation  Career  Field. 

28.  CAREER  FIELD  SUBDIVISION  -  The  third  digit  in  combination  with  the  first 
two  digits  of  the  airman  AFSC.  It  signifies  a  division  of  a  career 
field  into  which  closely  related  Air  Force  specialties  are  arranged 

in  one  or  more  ladders  to  indicate  lateral  functional  relationships. 

There  are  seven  career  field  subdivisions  under  Transportation  Career 
Field.  For  example,  605  . 

29.  CAREER  FIELD  SUBDIVISION  DESCRIPTION  -  A  statement  of  what  the  career 
field  subdivision  number  refers  to.  For  example,  603  indicates  Air 
Transportation  Career  Field. 

30.  CAREER  FIELD  LADDER  -  The  fourth  digit  of  an  airman  AFSC.  It  signifies 
a  vertical  arrangement  of  Air  Force  specialties  within  a  career  field 
subdivision  to  indicate  skill  distinction  and  progression.  For  example, 

6057. 

31.  CAREER  FIELD  LADDER  DESCRIPTION  -  A  -tatement  of  what  the  career  field 
ladder  number  refers  to.  For  example,  <->057_  the  level  of  technician 

or  supervisor  (advanced). 

32.  AIR  FORCE  SPECIALTY  -  Tile  fifth  digit  of  an  airman  AFSC  in  combination 

with  the  first  four  digits.  It  signifies  a  functional  grouping  of  positions 
related  in  terms  of  education,  training,  experience,  and  ability  qualifications. 
For  example,  6057(1* 

i3.  AIR  FORCE  SPECIALTY  DESCRIPTION  -  A  statement  of  what  the  Air  Force 

specialty  number  refers  to.  For  example,  6Q57£  indicates  Air  Transporta¬ 
tion  Supervisor. 
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3<*.  AIR  FORCE  SPECIALTY  SHREDOUT  -  An  alphabetical  suffix  on  an  officer  or 
airman  AFSC.  It  signifies  qualification  with  specific  equipment  or 
functions  encompassed  by  that  Air  Force  specialty.  For  example,  Z. 

35*  AIR  FORCE  SPECIALTY  SHREDOUT  DESCRIPTION-  A  statement  of  what  the 
alphabetical  suffix  refers  to.  For  example,  60570Z_  indicates  the 
C-5A  aircraft. 

36.  AIR  FORCE  SPECIALTY  PREFIX  -  An  alphabetical  prefix  on  an  officer  cr 
airman  AFSC.  It  signifies  an  ability  or  skill  not  restricted  to  a  single 
utilization  field  or  career  field.  For  example,  L. 

37.  AIR  FORCE  SPECIALTY  PREFIX  DESCRIPTION-  A  statement  of  what  the  alphabetical 
prefix  refers  to.  For  example,  L  indicates  Latin  America  Area  Specialist. 

38.  EQUIPMENT  TYPE  -  A  fundamental  grouping  of  hardware.  The  criterion  for 
determining  whether  or  not  a  unit  of  equipment  should  be  class! fi  \  as 
a  type  will  depend  upon  whether  it  is  a  part  of  a  larger  assembly  or  is 
independent.  For  example,  aircraft  is  a  type  of  equipment  because  it 
is  functions,  ly  complete  item  in  itself  and  not  a  part  of  a  larger 
equipment  grouping. 

39.  PROPULSION  UNIT  -  The  type  of  power  source  used  to  propel  the  vehicle. 

For  example,  Jet,  reciprocating  engine  or  rocket  engine. 

1*0.  FUNCTION  -  The  major  purpoc •»  for  which  a  type  of  equipment  will  Le  used. 

For  example,  equipment  t/pe  is  aircraft,  the  function  is  bomber.  Function 
does  not  specify  what  kind  of  bomber  it  is. 

1*1.  SUBTYPE  -  A  modifier  of  function  that-  makes  its  meaning  more  precise. 

For  example,  function  is  bomber,  subtype  is  heavy  bomber. 

1*2.  MODEL  -  An  alphanumeri c  designator  which  specifies  a  particular  distinctive 
grouping  of  an  equipment  subtype.  For  example,  subtype  is  heavy  bomber,  med¬ 
ia  B-52. 
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V3.  MODIFICATION  -  A  sequentially  arranged  series  of  alphabetic  designators 

j 

starting  with  A_  vhich  indicates  physical  alterations  to  an  equipment  j 

model  to  change  its  capabilities  cr  character: sties .  For  example,  model 
B-52,  modification  11 . 

Uh.  SERIAL  NUMBER  -  An  alphanumeric  designator  which  uniquely  identifies 

an  individual  uni+  of  equipment.  It  is  not  meant  tc  designate  identical 
units  of  equipment.  A  serial  number  will,  for  example ,  identify  one 

particular  B-S2H  from  all  others.  f 

i»'),  MAJOR  COMPONENT  MEMBER  (repeating  group  in  Subtask)  -  A  basic  j 

indispensable  segment  of  a  unit  of  equipment.  For  example,  the  major  com-  | 

ponents  of  an  aircraft,  include  the  fuselage,  empennage,  wings,  landing  : 

gear  (minus  tires)  and  engines.  Ma,t  "  components  do  not  include  accessories 
or  other  pares  th-t  ma^'  be  replaced  from  time  tc  time. 

kb.  MAJOR  COMPONENT  -  A  particular  major  component  of  a  unit  of  equipment 
under  consideration,  ror  example ,  engine. 

1*7.  COMPONENT  MEMBER  (repeating  group  ir.  major  'orpor.-'-rt  }  -  A  self- 

contained  unit,  which,  performs  a  function  necessary  to  the  proper  operation 

of  a  module,  subsystem,  or  system  of  which,  it  os  a  part.  For  example,  = 

a  generator  and  a  gyroscope  are  component  s  of  ar  aircraft.  A  component 

may  or  may  not  be  a  member  of  a  major  c  over.*  r:t  . 


form  a  portion  of  an  assembly  or  component,  replaceable  as  a  whole, 
and  having  a  part  or  parts  which  are  individually  replaceable. 

52.  SUBASSEMBLY  -  Designates  a  particular  subassembly  of  an  equipment  assembly 
under  consideration.  For  example,  a  radio  receiver  tuner  bandspread. 

53.  PART  MEMBER  (repeating  gi  ">up  in  subassembly)  -  An  individual  piece  or 
member  of  an  equipment  subassembly . 

51*.  PART  -  Designates  a  particular  individual  piece  c.  member  of  an  equip¬ 
ment  subassembly.  For  example,  variable  tuning  capacitor. 
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APPENDIX  XII 
TIME-LINE  PRINTOUTS 
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TIME-LINE  PRINTOUT 


A  capability  exi-.s  to  output  a  crude  time-line  using  TDMS,  COMPOSE  and  the 
data  in  the  experimental  data  pool .  Time-line  outputs  are  limited  to  the 
teletypewriter  console  characteristics  which  allow  a  single  line  output 
lengtn  of  TO  characters  or  spaces.  Therefore,  by  using  the  column  or  angle 
commands  of  query  and  specifying  the  maximum  number  of  characters  and  spaces 
outputs  similar  to  Figures  2S ,  26,  and  27  are  possible. 


MISSION 

OPERATOR 

OPERATOR 

OPERATOR 

0PERAT0 

TIME 

SUB  TASK 

SUB  TASK 

SUB  TASK 

SUB  TAS 

(MINUTES) 

10552 

1045 

1585 

1535 

372. 0C 

28-1 

28-1 

26-2 

27. 4 

372.25 

r — 1 

1 

CO 

(\i 

28-14 

28-2 

27-4 

372.50 

28-1 

28-4 

28-2 

372.75 

OP  T 

28-4 

28-2 

373.00 

28-1 

28-4 

28-3 

28-6 

373.25 

28-1 

28-4 

28  '< 

28-6 

373.50 

28-1 

28-3 

28-6 

373-75 

28-1 

26-3 

28-6 

37^.00 

!/>> 

1 

CO 

C\J 

28-3 

28-6 

Figure  25  .  T? 

ime-Line 

/  Mission  Time 

Figure  25  presents  a  simulation  processing  output  *hat  permits  the  comparison 
between  various  erev  members  performing  tasks  by  task  computer  element  (28) 
and  sub-task  computer  element  (28-1 )  number  as  a  function  of  elapsed  time 
Within  a  mission  time.  Blanks  signify  that  an  operator  does  not  have  an 
assigned  task  during  this  time  segment.  Since  most  of  the  task  numbers  are 
within  compute.  element  (28),  it  must  be  assumed  that  the  tasi  number  (2 7-4) 
being  performed  by  an  operator  (AFSC  1535)  is  a  carry-over  from  the  previous 
time  segment.  A  further  generalization  may  also  be  made;  operators  (AFSC 
105R2  and  AFSC  1585)  are  active  100)6  of  the  time  during  this  time  segment, 
and  operators  (AFSC  1045  and  1535)  have  0.75  and  0.50  minutes  of  uncommitted 
time  during  this  time  segment. 

START  STOP  TASK 


OFERATOR 

SI 

TIME 

TIME 

NO 

SEGMENT 

LOCATION 

HELPER 

HR  IT 

DIFF 

1055Z 

1 

272.58  272.61 

28-1 

TAXI 

WA#1PILCT 

10570 

NA 

NA 

105T0 

1 

272.58 

272.61 

28-2 

TAXI 

WA#5CARG0 

NA 

NA 

10550 

1 

272.58 

272.61 

28-5 

TAXI 

WA* 5 CARGO 

NA 

NA 

1585 

1 

272.58 

272.61 

27-6 

CONT 

TAXI 

WA#IFTENC 

MOD 

LOW 

1535 

1 

272.58 

272.61 

28-4 

TAXI 

WA01NAV 

VRY 

VRY 

1585 

1 

272.58 

272.61 

28-3 

TAXI 

WA01FTENG 

LOW 

LOW 

Figure  26  Mission  Segment  Task  Time-Line 
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Figure 26  presents  a  simulation  output  that  permits  a  slightly  different 
conf.. guration  of  operator  task  assignments  during  a  specified  mission  seg¬ 
ment.  This  arrangement  of  the  data  is  by  operator  and  task  start /stop  time 
values.  The  output  also  contains  some  additional  information  (Mission 
Segment,  Location,  Helper,  Task  Criticality,  and  Task  Derformanee  Difficulty). 
Thus,  the  time-line  may  'ce  individually  structured  by  the  system  user  to  con¬ 
tain  and  order  only  those  data  elements  or  data  element  values  selected  from 
the  data  pool. 


TIME 

TASK 

TASK 

SEG 

OPERATOR 

QTY 

TIME 

NO 

LOCATION 

EQUIPMENT 

125 

13270 

J± 

135 

176-1 

wa#38fltln 

ALIGNMENT  FIXTURE  A00108A 

BEAM  TYPE  SLING  MR0228A 

13250 

02 

ENGINE  MAIN?  STAND  NOSE 

13230 

01 

COWL  ENGINE  INSTALLATION 

PIN  KIT 

126 

13250 

02 

tr 

\o 

CO 

176-2 

WA#l0SKCP 

AS  ABOVE  FOR  TASK  176-1  PLUS 
TRANSPORTER  TRUCK 

127 

43270 

01 

528.5 

176.3 

WA#!6r>FCTY 

AS  FOR  176-2  LESS  TRUCK  PLUS 
RAIL-TYPE  TRANSPORTATION  TRAILER 
MR 02 18A  COMMON  HAND  TOOLS 

figure  Maintenance  Task  Time-Line 

Figure  27  provides  a  third  look  at  an  initial  time-line  based  upon  maintenance 
data  from  the  experimental  data  pool.  In  this  example  the  display  ordering 
is  based  on  an  artificially  imposed  element— Time  Segment — because  unscheduled 
maintenance  must  include  some  type  of  a  hierarchical  indexing  scheme  to  assist 
in  implementing  retrieval.  Therefore,  this  maintenance  time-line  is  ordered 
by  time  segment  and  operator.  Further,  this  output  contains  user  specified 
qualifiers:  quantitj  of  operators,  task  identifying  number,  task  location, 
and  equipment  required. 
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SIMULATION  OUTPUT  TECHNIQUE 
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SIMULATION  OUTPUT 


D.  A.  Wilson  (1967),  of  the  U.  S.  Naval  Personnel  Research  Activity,  San  Diego, 
California  developed  a  scheme  for  automating  Operational  Sequence  Diagrams 
(OSD).  The  OSD  is  a  specialized  form  of  task  analysis  output  developed  for  the 
U.  S,  Navy.  It  does  not  replace  the  requirements  for  a  complete  task  analysis. 
This  methodology,  with  some  minor  modifications,  can  be  programmed  as  the  fixed 
format  output,  for  PSES,  of  a  time-line  or  simulation  run.  This  appendix  pro¬ 
vides  an  example  of  the  simulation  output  available  using  the  OSD  techniques. 
The  behavior  codes  used  are  as  shown  below: 


FIRST  LETTER  H(HUMAN) 

HUMAN  OR  MACHINE  M(MACHINE) 

A (ACT) 

D( DECADE) 

T(TRANSMIT) 

R (RECEIVE) 

S( STORE) 

P(USE  PREVIOUSLY  STORED  INFORMATION) 
S (SPEECH) 

P( PHONE,  SOUND-POWER ) 

I (INTERCOM) 

E( ELECTRICAL  OR  ELECTRONIC) 

T( TOUCH) 

VISUAL) 

F( FILED) 

FOliRTH  LETTER  D( DISPLAYED) 

DISPLAYED  OR  NOT  BLANK (NOT  DISPLAYED) 


FIFTH  LETTER  G(GO,  YES  NORMAL,  ETC.) 

INVERSE  MEANING  N( NO-GO,  NO,  ABNORMAL.  ETC.) 

It  is  anticipated  that  these  behavior  codes  would  be  included,  at  periodic 
intervals  on  the  printout,  to  reduce  memorization  and  human  error. 

Figure  28  represents  the  output  of  either  a.  time-line  from  stored  data  or 
simulation  run  in  a  proposed  fixed  format . 

Figure  29  is  the  same  information  with  the  addition  of  heading  and  columnar 
lines  drawn  to  show  the  sequence  of  operation  and  interrelated  man  or  equip¬ 
ment  operations  necessary. 


THIRD  LETTER 

MEANS  OF  PERFORMANCE 


SECOND  LETTER 
BEHAVIOR 

I 
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Research  leading  to  the  application  and  implementation  of  techniques  for 
computer  handling  of  human  factors  t*s'»  data  generated  in  support  of  aerospace 
system,  development  programs  is  discussed.  The  technique  development  is  based  on 
the  assumption  that  a  user- orients,  computerised  data  handling  ays  ten  m„  1 
help  draw  human  factors  specialists  closer  to  needed  data.  The  application  of 
these  techniques  should  reduce  the  prjblam  of  data  accessibility  and  allow  more 
ef: active  use  ol  data  in  the  system  design  and  development  process.  A  coa^uter- 
i-®d  data  handling  system  to  store,  selectively  retrieve,  and  process  hussar, 
factors  data  in  a  user-oriented  environment  was  iapl  oriented  through  a  Pilot 
otudy  Experimental  System  (PSSS).  This  experimental  system  provided  the  priaarv 


means  for  evaluating  the  research  rest 


This  report  discusses  the  dccelcp- 


mur.t.  process  of  the  ?SE:,  the  -orputer  software  use:  by  the  PSSS,  data  classi¬ 
fies*:.  .i  techniques ,  arrc  vocabulary  controls,  tonslderaticr.  is  also  give"  to 
'•he  feasibility  of  providing  (1)  analytic  and  simulation  tools  ir.  a  user-orient 
mvi  ro resent,  (2)  current  awareness  notification  of  ia'a  entries,  and  (3)  an 
advanced  and  sophisticated  classification  scheme  for  identifying  functional 
relationships. 
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